"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> (I'm not sure how optimized UNION inside an IN/NOT IN is.)
NOT IN is pretty nonoptimal, period. It'd help a lot to boost work_mem
to the point where the planner figures it can use a hashtable (look for
EXPLAIN to say "hashed subplan" rather tha
On Wed, 7 Sep 2005, Meetesh Karia wrote:
> PG is creating the union of January, February and March tables first and
> that doesn't have an index on it. If you're going to do many queries using
> the union of those three tables, you might want to place their contents into
> one table and create an
PG is creating the union of January, February and March tables first
and that doesn't have an index on it. If you're going to do many
queries using the union of those three tables, you might want to place
their contents into one table and create an index on it.
Otherwise, try something like this:
On Wed, Sep 07, 2005 at 12:22:27PM -0400, Christian Compagnon wrote:
> I'm a newbie in postgresql, I've installed it on a Windows XP machine
> ( I can't use linux, it's a company machine ), I'm courious why this
> query takes so long
It sounds like you've set work_mem too low; increasing it might
