Nikita Malakhov <hukutoc@gmail.com> writes:
> Hi,
>
> Andy, thank you, I've checked this thread out along with run-time
> partition pruning.
I'm not sure the relationshipe between this topic and run-time
partitioin pruning..
> I've spend some time hovering on the tuple_fraction field usage and would disagree
> with you on this topic - it is already used on the RelOptInfo level later on, in
> generate_orderedappend_paths()
Looks you are right that root->tuple_fraction has been used on RelOptInfo
level in the generate_orderedappend_paths(). But we also tried to
use not in the RelOptInfo level such as set_subquery_pathlist. See..
"""
/*
* We can safely pass the outer tuple_fraction down to the subquery if the
* outer level has no joining, aggregation, or sorting to do. Otherwise
* we'd better tell the subquery to plan for full retrieval. (XXX This
* could probably be made more intelligent ...)
*/
"""
I'm not sure the "more intelligent" would be just use it directly.
So I'm not saying we can't do this, just that the facts are:
(a). root->tuple_fraction are not exactly same as RelOptInfo's
tuple_fraction.
(b). We have used root->tuple_fraction in RelOptInfo in some cases and
also tried to not use it in some other case (and only use it under some
situation similar like what I did before).
Looks different committers have different opinion on this.
--
Best Regards
Andy Fan