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
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
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
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
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 think
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 older. But
