Jeremy M. Guthrie [EMAIL PROTECTED] writes:
My system will run great after a full vacuum(as I would expect). It will run
all day long taking only 3-5 seconds to run and deal with approximately
100megs of new data each day. However, the instant the system finishes only
a 'vacuum
On Sat, 19 Jul 2003, Jeremy M. Guthrie wrote:
100megs of new data each day. However, the instant the system finishes only
a 'vacuum analyze', the whole thing slows WAY down to where each run can take
10-15 minutes.
Have you run EXPLAIN ANALYZE on the delete query before and after the
Michael Pohl wrote:
On Sun, 6 Jul 2003, Matthew Nuzum wrote:
At the very least, if there is good documentation for these parameters,
maybe the conf file should provide a link to this info.
I believe that is what Josh is proposing:
I think the issue with multiple users is that a car is good for moving a
few people, but it can't move lots of large boxes. A truck can move
large boxes, but it can't move a few people efficiently. PostgreSQL is
more like a truck, while MySQL is more like a car.
As an aside, I think Solaris is
Brian Tarbox wrote:
Oddly enough, the particular application in question will have an extremely
small user base...perhaps a few simultainous users at most.
As to the testing, I neglected to say early in this thread that my manager
instructed me _not_ to do further performance testing...so as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I looked back at my code and I also need to reclarify something. The delete
at the end is multiple delete statements within a transaction.
After full vacuum with 160,000 records in Table: (takes a bit the first time
through)
Tlog=# explain
I can help with this too.
---
scott.marlowe wrote:
I'm willing to help too. I'm basically a DBA / developer type, with mild
C hacking skills (I develop in PHP, so my C coding is quite rusty
nowadays.)
If nothing
Jeremy M. Guthrie [EMAIL PROTECTED] writes:
I looked back at my code and I also need to reclarify something. The delete
at the end is multiple delete statements within a transaction.
I think you are going to have to show us all the details of what you're
doing in between these queries. I was
Alexandre,
I missed your orig. post, but AFAIK multiprocessing kernels will handle HT
CPUs as 2 CPUs each. Thus, our dual Xeon 2.4 is recognized as 4 Xeon 2.4
CPUs.
This way, I don't think HT would improve any single query (afaik no postgres
process uses more than one cpu), but overall
Dear Gurus,
I have a query discussed here earlier that suffers heavily from lack of
view flattening in v7.3. Following Tom's guidance, I made a conclusion to
that thread
(http://archives.postgresql.org/pgsql-performance/2003-05/msg00215.php)
and asked it to be confirmed or fixed, but I didn't get
10 matches
Mail list logo
