Re: Considering fractional paths in Append node - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Considering fractional paths in Append node
Date
Msg-id 87cyjj7q88.fsf@163.com
Whole thread Raw
In response to Considering fractional paths in Append node  (Nikita Malakhov <hukutoc@gmail.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: define pg_structiszero(addr, s, r)
Next
From: KAZAR Ayoub
Date:
Subject: Questions About TODO: Issuing NOTICEs for row count differences in EXPLAIN ANALYZE