Re: 8.4 semi-join slows down query performance (EXISTS) - Mailing list pgsql-hackers

From steven king
Subject Re: 8.4 semi-join slows down query performance (EXISTS)
Date
Msg-id 20090421121001.281470@gmx.net
Whole thread Raw
In response to Re: 8.4 semi-join slows down query performance (EXISTS)  (Guillaume Smet <guillaume.smet@gmail.com>)
List pgsql-hackers
I hope this will treat as a "planner-bug". I think the problem is tricky but not hard to solve.

-------- Original-Nachricht --------
> Datum: Tue, 21 Apr 2009 13:53:01 +0200
> Von: Guillaume Smet <guillaume.smet@gmail.com>
> An: vacuum@quantentunnel.de
> CC: pgsql-hackers@postgresql.org
> Betreff: Re: [HACKERS] 8.4 semi-join slows down query performance (EXISTS)

> On Tue, Apr 21, 2009 at 11:38 AM,  <vacuum@quantentunnel.de> wrote:
> > I've queries returning tupels of A, with a (sub-)selected
> constant-expression that indicates whether a referenced tupel exists in B or not. For
> this issue the EXISTS clause is used.
> >
> > In past (8.3) the planner resolves this into index-scans using existing
> foreign-key indices -> fast query (1.5 seconds for comparison). Now (in
> 8.4) the planner wants "semi-joins". Index-scans are not longer used and my
> query needs 600 seconds to return.
> 
> That worries me a bit for one of our applications too. We use EXISTS
> in several places to trick the planner when the statistics are way off
> (cross columns/cross tables) and I'm not sure making EXISTS more
> clever will help us.
> 
> -- 
> Guillaume
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!*
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Automating Partitions in PostgreSQL - Query on syntax
Next
From: Heikki Linnakangas
Date:
Subject: Re: New trigger option of pg_standby