Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
| От | Alvaro Herrera |
|---|---|
| Тема | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
| Дата | |
| Msg-id | 20041111012131.GF15213@surnet.cl обсуждение исходный текст |
| Ответ на | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
| Список | pgsql-hackers |
On Wed, Nov 10, 2004 at 07:18:59PM -0500, Tom Lane wrote: > A more radical way of handling it would be to detect the relevance of an > indexscan in indxpath.c and generate a special kind of Path node; this > would not generalize to other sorts of things as you were hoping, but > I'm unconvinced that the mechanism is going to be very general-purpose > anyway. The major advantage is that this would work conveniently for > comparing the cost of a rewritten query to a non-rewritten one. What about having a new column in pg_aggregate which would point to a function that would try to optimize the aggregate's handling? There could be multiple calls to that function along the query's way to executor, each one at a different point (with a parameter specifying which one it is), that would try to rewrite the query optimizing the aggregate. So we could optimize some aggregates at one point, and others at a different point, whichever makes the most sense. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
В списке pgsql-hackers по дате отправления: