From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | "Marcus Andree S(dot) Magalhaes" <marcus(dot)magalhaes(at)vlinfo(dot)com(dot)br> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: optimizing large query with IN (...) |
Date: | 2004-03-10 17:51:18 |
Message-ID: | Pine.LNX.4.33.0403101050150.10418-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I'm not sure exactly what you're saying here. If the data in the in()
clause comes from a complex select, then just use the select in there, and
bypass the temporary table idea.
I'm not sure what a temporary database is, did you mean temporary table?
if so, then my above comment addresses that point.
On Wed, 10 Mar 2004, Marcus Andree S. Magalhaes wrote:
>
> Hmm... from the 'performance' point of view, since the data comes from
> a quite complex select statement, Isn't it better/quicker to have this
> select replaced by a select into and creating a temporary database?
>
>
>
> > The problem, as I understand it, is that 7.4 introduced massive
> > improvements in handling moderately large in() clauses, as long as they
> > can fit in sort_mem, and are provided by a subselect.
> >
> > So, creating a temp table with all the values in it and using in() on
> > the temp table may be a win:
> >
> > begin;
> > create temp table t_ids(id int);
> > insert into t_ids(id) values (123); <- repeat a few hundred times
> > select * from maintable where id in (select id from t_ids);
> > ...
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Harrison | 2004-03-10 19:08:50 | Re: syslog slowing the database? |
Previous Message | Josh Berkus | 2004-03-10 17:35:47 | Re: Cluster and vacuum performance |