Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
От | Tom Lane |
---|---|
Тема | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Дата | |
Msg-id | 2089.1100132339@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | MAX/MIN optimization via rewrite (plus query rewrites generally) (Mark Kirkwood <markir@coretech.co.nz>) |
Ответы |
Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
Re: MAX/MIN optimization via rewrite (plus query rewrites |
Список | pgsql-hackers |
Mark Kirkwood <markir@coretech.co.nz> writes: > I am looking at implementing this TODO item. e.g. (max case): > My initial thoughts revolved around extending the existing RULE system > to be able to handle more general types of rewrite - like conditionals > in SELECT rules and rewrites that change elements of the query other > than the target relation. The rule rewriter is almost certainly the wrong place, because it has only the most superficial understanding of a query's semantics. Doing this processing there would require re-inventing (or at least duplicating the execution of) a lot of the planner's query analysis work. My thoughts would run towards doing this after the prepqual and prepjointree steps (probably somewhere in grouping_planner). Even there is a bit early since you'd have to duplicate plancat.c's extraction of information about related indexes; but possibly it'd be reasonable to move the add_base_rels_to_query() call out of query_planner and do it in grouping_planner. 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. How are you planning to represent the association between MIN/MAX and particular index orderings in the system catalogs? regards, tom lane
В списке pgsql-hackers по дате отправления: