Re: suggestion to improve planer
От | Peter Eisentraut |
---|---|
Тема | Re: suggestion to improve planer |
Дата | |
Msg-id | 1252498301.15729.8.camel@fsopti579.F-Secure.com обсуждение исходный текст |
Ответ на | suggestion to improve planer (Ľubomír Varga <luvar@plaintext.sk>) |
Ответы |
Re: suggestion to improve planer
|
Список | 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 по дате отправления: