On 2011-06-29 19:22, Hitoshi Harada wrote:
Other things are all good points. Thanks for elaborate review!
More than anything, I'm going to fix the 6) issue, at least to find the cause.
Some more questions:
8) why are cheapest start path and cheapest total path in
best_inner_subqueryscan the same?
9) as remarked up a different thread, more than one clause could be
pushed down a subquery. The current patch only considers alternative
paths that have at most one clause pushed down. Is this because of the
call site of best_inner_subqueryscan, i.e. under one join rel? Would it
be an idea to consider, for each subquery, only a single alternative
plan that tries to have all suitable clauses pushed down?
10) I have a hard time imagining use cases that will actually result in
a alternative plan, especially since not all subqueries are allowed to
have quals pushed down into, and like Simon Riggs pointed out that many
users will write queries like this with the subqueries pulled up. If it
is the case that the subqueries that can't be pulled up have a large
overlap with the ones that are not pushdown safe (limit, set operations
etc), there might be little actual use cases for this patch.
I think the most important thing for this patch to go forward is to have
a few examples, from which it's clear that the patch is beneficial.
regards,
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
