Re: suggestion to improve planer - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: suggestion to improve planer
Date
Msg-id 1252498301.15729.8.camel@fsopti579.F-Secure.com
Whole thread Raw
In response to suggestion to improve planer  (Ľubomír Varga <luvar@plaintext.sk>)
Responses Re: suggestion to improve planer
List pgsql-hackers
On Thu, 2009-09-03 at 10:35 +0200, Ľubomír Varga wrote:
> Hi.
> 
> I hope, that this is right mailing list.
> 
> SELECT date, value FROM t_event
>     WHERE t_event.id in (SELECT id FROM t_event
>         WHERE date < '2009-08-25'
>         ORDER BY date DESC LIMIT 1)
>     ORDER BY date;
> cost 6.4
> 
> SELECT date, value FROM t_event
>     WHERE t_event.id = (SELECT id FROM t_event
>         WHERE date < '2009-08-25'
>         ORDER BY date DESC LIMIT 1)
>     ORDER BY date;
> cost 6.36..6.37
> 
> 
> Why that two query dont have equal cost? If it is not problem, try add some 
> planer code to recognize that sublesect HAVE TO return just one row (limit 1) 
> and in plan could be used filter/index scan instead of hash aggregate.

Well, there is always a tradeoff between more planner analysis and more
complicated and slow planning.  Seeing that the cost estimates are close
enough for practical purposes, it doesn't seem worthwhile to fix
anything here.

>  I have 
> also some complex query examples where cost difference is more visible.

Having real examples where a change might actually improve runtime is
always more interesting than an academic exercise like the above.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: RfD: more powerful "any" types
Next
From: Peter Eisentraut
Date:
Subject: Re: COALESCE and NULLIF semantics