From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | luvar(at)plaintext(dot)sk |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: suggestion to improve planer |
Date: | 2009-09-09 12:11:41 |
Message-ID: | 1252498301.15729.8.camel@fsopti579.F-Secure.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-09-09 12:13:32 | Re: COALESCE and NULLIF semantics |
Previous Message | Alvaro Herrera | 2009-09-09 11:47:22 | Re: RfD: more powerful "any" types |