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

From Andreas Pflug
Subject Re: IN list processing performance (yet again)
Date
Msg-id 3ED4B75A.2050106@web.de
Whole thread Raw
In response to IN list processing performance (yet again)  (Dave Tenny <tenny@attbi.com>)
Responses Re: IN list processing performance (yet again)
List 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 by date:

Previous
From: Shridhar Daithankar
Date:
Subject: Re: IN list processing performance (yet again)
Next
From: "Mario Weilguni"
Date:
Subject: Re: IN list processing performance (yet again)