Re: IN list processing performance (yet again)
От | Dave Tenny |
---|---|
Тема | Re: IN list processing performance (yet again) |
Дата | |
Msg-id | 3ED5159E.2050407@attbi.com обсуждение исходный текст |
Ответ на | Re: IN list processing performance (yet again) (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: IN list processing performance (yet again)
|
Список | pgsql-performance |
Bruno Wolff III wrote:
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.
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 по дате отправления: