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)  (Bruno Wolff III <bruno@wolff.to>)
Список 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 по дате отправления:

Предыдущее
От: Dave Tenny
Дата:
Сообщение: Re: IN list processing performance (yet again)
Следующее
От: Dave Tenny
Дата:
Сообщение: Re: IN list processing performance (yet again)