Re: [PERFORM] ugly query slower in 7.3, even slower after vacuum full analyze

2003-07-20 Thread SZŰCS Gábor
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 ge

Re: [PERFORM] Dual Xeon + HW RAID question

2003-07-20 Thread SZUCS Gábor
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 multi-quer

Re: [PERFORM] Poor delete performance AFTER vacuum analyze

2003-07-20 Thread Tom Lane
"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.

Re: [PERFORM] [pgsql-advocacy] About the default performance

2003-07-20 Thread Bruce Momjian
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 nothin

Re: [PERFORM] Poor delete performance AFTER vacuum analyze

2003-07-20 Thread Jeremy M. Guthrie
-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 analyze

Re: [PERFORM] PostgreSQL vs. MySQL

2003-07-20 Thread Bruce Momjian
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...s

Re: [PERFORM] PostgreSQL vs. MySQL

2003-07-20 Thread Bruce Momjian
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 s

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-20 Thread Bruce Momjian
Keep in mind that if we auto-tune, we will only be able to do it for some platforms, so we will need a table that shows which settings are autotuned for each platform. --- Sean Chittenden wrote: > > I don't have much to add

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-20 Thread Bruce Momjian
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: > > http://archives.postgresql.org/pgsql-perform