On Sun, Feb 25, 2007 at 01:34:44PM -0500, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > If 8.2, what about
> >... WHERE foo IN (select x from (values (1$),(2$),...,(N$)) as t(x))
> > ?
>
> Well, the OP wasn't using 8.2 --- judging from the selected plan, it had
> to be 8.0 or ol
Joe Conway <[EMAIL PROTECTED]> writes:
> If 8.2, what about
>... WHERE foo IN (select x from (values (1$),(2$),...,(N$)) as t(x))
> ?
Well, the OP wasn't using 8.2 --- judging from the selected plan, it had
to be 8.0 or older. But yeah, a values-list is an interesting
alternative on 8.2. I t
Tom Lane wrote:
Richard Jones <[EMAIL PROTECTED]> writes:
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
PG 8.2 does better with long IN-lists ... although if the list is so
long as to be fetching a significant f
Richard Jones <[EMAIL PROTECTED]> writes:
> I've been profiling a PG database / mix of applications and found that
> one statement which takes a very long time to execute is:
PG 8.2 does better with long IN-lists ... although if the list is so
long as to be fetching a significant fraction of the t
Richard,
contrib/intarray may help you.
On Sun, 25 Feb 2007, Richard Jones wrote:
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
select e.keywordid, e.quantity, e.max_cpc, i.position
from bid3_events_imp
I've been profiling a PG database / mix of applications and found that
one statement which takes a very long time to execute is:
select e.keywordid, e.quantity, e.max_cpc, i.position
from bid3_events_impressions i, bid3_events e
where i.eventid = e.id and e.keywordid in ($1,$2,$3,
