Re: [PERFORM] [pgsql-hackers-win32] Poor Performance for large queries in functions

2004-09-29 Thread John Meinel
Tom Lane wrote: John Meinel [EMAIL PROTECTED] writes: ... However, if I try to bundle this query up into a server side function, it runs very slow (10 seconds). I'm trying to figure out why, but since I can't run EXPLAIN ANALYZE inside a function, I don't really know what else to do. A

Re: [PERFORM] [pgsql-hackers-win32] Poor Performance for large queries

2004-09-29 Thread Richard Huxton
John Meinel wrote: So notice that when doing the actual select it is able to do the index query. But for some reason with a prepared statement, it is not able to do it. Any ideas? In the index-using example, PG knows the value you are comparing to. So, it can make a better estimate of how many

Re: [PERFORM] This query is still running after 10 hours...

2004-09-29 Thread Steven Rosenstein
Hi Robert, There is no significant disk activity (read 0), one CPU is pegged, and that process is consuming 218M Resident memory, 168M Shared (10% available memory total). All reasonable, except for the fact it doesn't come back... Just to let you know, I've observed the identical phenomenon

Re: [PERFORM] Interest in perf testing?

2004-09-29 Thread Shea,Dan [CIS]
What is involved, rather what kind of help do you require? Dan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Josh Berkus Sent: Tuesday, September 28, 2004 1:54 PM To: [EMAIL PROTECTED] Subject: [PERFORM] Interest in perf testing? Folks, I'm

Re: [PERFORM] [pgsql-hackers-win32] Poor Performance for large queries

2004-09-29 Thread John Meinel
Richard Huxton wrote: John Meinel wrote: So notice that when doing the actual select it is able to do the index query. But for some reason with a prepared statement, it is not able to do it. Any ideas? In the index-using example, PG knows the value you are comparing to. So, it can make a

Re: [PERFORM] [pgsql-hackers-win32] Poor Performance for large queries in functions

2004-09-29 Thread Tom Lane
[ enlarging on Richard's response a bit ] John Meinel [EMAIL PROTECTED] writes: jfmeinel= explain analyze execute myget(3); QUERY PLAN Seq Scan on tdata

Re: [PERFORM] [pgsql-hackers-win32] Poor Performance for large queries

2004-09-29 Thread John Meinel
Tom Lane wrote: [ enlarging on Richard's response a bit ] John Meinel [EMAIL PROTECTED] writes: jfmeinel= explain analyze execute myget(3); QUERY PLAN Seq Scan on tdata

[PERFORM] stubborn query confuses two different servers

2004-09-29 Thread SZCS Gbor
Dear Gurus, Here is this strange query that can't find the optimum plan unless I disable some scan modes or change the costs. (A) is a 2x2.4GHz server with hw raid5 and v7.3.4 database. It chooses hashjoin. (B) is a 300MHz server with 7200rpm ide and v7.4.2 database. It chooses seqscan. If I

[PERFORM] index not used when using function

2004-09-29 Thread Shiar
Hi all, a small question: I've got this table songs and an index on column artist. Since there's about one distinct artist for every 10 rows, it would be nice if it could use this index when counting artists. It doesn't however: lyrics= EXPLAIN ANALYZE SELECT count(DISTINCT artist) FROM songs;

Re: [PERFORM] Interest in perf testing?

2004-09-29 Thread Gaetano Mendola
Josh Berkus wrote: Folks, I'm beginning a series of tests on OSDL's Scalable Test Platform in order to determine some recommended settings for many of the new PostgreSQL.conf parameters as well as pg_autovacuum. Is anyone else interested in helping me with this? What do you need ? Regards

Re: [PERFORM] O_DIRECT setting

2004-09-29 Thread Mark Wong
On Thu, Sep 23, 2004 at 10:57:41AM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: TODO has: * Consider use of open/fcntl(O_DIRECT) to minimize OS caching Should the item be removed? I think it's fine ;-) ... it says consider it, not do it. The point is that we could

Re: [PERFORM] O_DIRECT setting

2004-09-29 Thread Tom Lane
Mark Wong [EMAIL PROTECTED] writes: I talked to Jan a little about this during OSCon since Linux filesystems (ext2, ext3, etc) let you use O_DIRECT. He felt the only place where PostgreSQL may benefit from this now, without managing its own buffer first, would be with the log writer. I'm