Re: Query take 101 minutes, help, please

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query take 101 minutes, help, please
Date: 2005-09-07 17:57:36
Message-ID: 28614.1126115856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)com> 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 than just "subplan"). Of course,
if there's enough stuff in the UNION that that drives you into swapping,
it's gonna be painful anyway.

Using UNION ALL instead of UNION might save a few cycles too.

If you're willing to rewrite the query wholesale, you could try the old
trick of a LEFT JOIN where you discard rows for which there's a match,
ie, the righthand join value isn't NULL.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alex Hayward 2005-09-07 18:40:57 Re: Query take 101 minutes, help, please
Previous Message Meetesh Karia 2005-09-07 17:09:39 Re: Query take 101 minutes, help, please