From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Atul Deopujari" <atul(dot)deopujari(at)enterprisedb(dot)com> |
Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning large IN lists |
Date: | 2007-05-17 13:34:38 |
Message-ID: | 23045.1179408878@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Atul Deopujari" <atul(dot)deopujari(at)enterprisedb(dot)com> writes:
> Hi,
> Tom Lane wrote:
>> That's the least of the problems. We really ought to convert such cases
>> into an IN (VALUES(...)) type of query, since often repeated indexscans
>> aren't the best implementation.
>>
> I thought of giving this a shot and while I was working on it, it
> occurred to me that we need to decide on a threshold value of the IN
> list size above which such transformation should take place.
I see no good reason to suppose that there is/should be a constant
threshold --- most likely it depends on size of table, availability of
indexes, etc. Having the planner try it both ways and compare costs
would be best.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-05-17 13:46:25 | Re: Not ready for 8.3 |
Previous Message | Bruce Momjian | 2007-05-17 13:24:07 | Re: BufFileWrite across MAX_PHYSICAL_FILESIZE boundary |