Re: IN list processing performance (yet again) - Mailing list pgsql-performance

From Dave Tenny
Subject Re: IN list processing performance (yet again)
Date
Msg-id 3ED5159E.2050407@attbi.com
Whole thread Raw
In response to Re: IN list processing performance (yet again)  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: IN list processing performance (yet again)  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-performance
Bruno Wolff III wrote:
On Wed, May 28, 2003 at 14:08:02 -0400, Dave Tenny <tenny@attbi.com> wrote: 
Andreas Pflug wrote:

I'm reminded to relay to the PostgreSQL devos that I might be able to do 
more in the  join or subquery department if
PostgreSQL had better performing MAX functions and a FIRST function for 
selecting rows from groups.
("Performing" being the operative word here, since the extensible 
architecture of PostgreSQL currently makes for poorly
performing MAX capabilities and presumably similar user defined 
aggregate functions).   
Have you tried replacing max with a subselect that uses order by and limit? 

I'm uncertain how that would work, since somewhere in there I still need to elaborate on the
1000 items I want, and they're not necessarily in any particular range, nor do they bear any
contiguous group nature.

Also, IN (subquery) is a known performance problem in PGSQL, at least if the subquery is going to return many rows.
It's too bad, since I'm rather fond of subqueries, but I avoid them like the plague in PostgreSQL.

Perhaps I don't understand what you had in mind.

pgsql-performance by date:

Previous
From: Dave Tenny
Date:
Subject: Re: IN list processing performance (yet again)
Next
From: Dave Tenny
Date:
Subject: Re: IN list processing performance (yet again)