Hi! I've checked set_subquery_pathlist(), and would rather say that it has a different purpose and I'd better not compare these functions directly.
generate_orderedappend_paths() was introduced 6 years ago, and commit that considers tuple_fraction authored by Tomas Vondra was suggested by Tom Lane himself. Also, generate_orderedappend_paths() is directly used in add_paths_to_append_rel(), so I don't see any reasons not to use tuple_fraction for the same purpose as it is used in generate_orderedappend_paths(). Maybe, let's wait what other reviewers would say? Thank you for your opinion and interest! I've corrected failing test and created a patch at Commitfest: https://commitfest.postgresql.org/51/5361/ Please check. On Tue, Oct 29, 2024 at 2:38 AM Andy Fan <zhihuifan1...@163.com> wrote: > 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 > > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/
v2-0001-append-limit-v1.patch
Description: Binary data
