Nikita Malakhov <huku...@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
