Re: IN list processing performance (yet again)

Поиск
Список
Период
Сортировка
От Andreas Pflug
Тема Re: IN list processing performance (yet again)
Дата
Msg-id 3ED4B75A.2050106@web.de
обсуждение исходный текст
Ответ на IN list processing performance (yet again)  (Dave Tenny <tenny@attbi.com>)
Ответы Re: IN list processing performance (yet again)
Список pgsql-performance
Dave Tenny wrote:

> Having grepped the web, it's clear that this isn't the first or last
> time this issue will be raised.
>
> My application relies heavily on IN lists.  The lists are primarily
> constant integers, so queries look like:
>
> SELECT val FROM table WHERE id IN (43, 49, 1001, 100002, ...)
>
> Performance is critical, and the size of these lists depends a lot on
> how the larger 3-tier applicaiton is used,
> but it wouldn't be out of the question to retrieve 3000-10000 items.
>
> PostgreSQL 7.3.2 seems to have a lot of trouble with large lists.
> I ran an experiment that ran queries on a table of two integers  (ID,
> VAL), where ID is a primary key and the subject
> of IN list predicates.  The test used a table with one million rows
> ID is appropriately indexed,
> and I have VACUUMED/analyzed the database after table load.
>
> I ran tests on in-lists from about 100 to 100,000 entries.

Hi Dave,

it sounds as if that IN-list is created by the application. I wonder if
there are really so many variances and combinations of it or whether you
could invent an additional column, which groups all those individual
values. If possible, you could reduce your IN list to much fewer values,
and probably would get better performance (using an index on that col,
of course).

Regards,

Andreas




В списке pgsql-performance по дате отправления:

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