From: | Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de> |
---|---|
To: | Dave Tenny <tenny(at)attbi(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: IN list processing performance (yet again) |
Date: | 2003-05-28 13:19:22 |
Message-ID: | 3ED4B75A.2050106@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2003-05-28 14:31:37 | Re: IN list processing performance (yet again) |
Previous Message | Shridhar Daithankar | 2003-05-28 13:16:38 | Re: IN list processing performance (yet again) |