Re: Potential Issue with Redundant Restriction Clauses in get_parameterized_baserel_size for PARTITIONED_REL

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: huyajun <hu_yajun(at)qq(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, feichanghong(at)qq(dot)com
Subject: Re: Potential Issue with Redundant Restriction Clauses in get_parameterized_baserel_size for PARTITIONED_REL
Date: 2024-11-26 13:20:31
Message-ID: CAMbWs49p-YLPviUWfQkkPq-sHG-A4HnhqU4d62Sy1_-DkxS6ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 26, 2024 at 4:57 PM huyajun <hu_yajun(at)qq(dot)com> wrote:
> The get_parameterized_baserel_size function does not differentiate for PARTITIONED_REL and always appends the rel's own restriction clauses. However, for PARTITIONED_REL, rel->tuples is computed in set_append_rel_size which comes from the sum of lived childrel->rows. It is important to note that childrel->rows is the estimated number of result tuples, meaning it already includes the effect of the rel's own restriction clauses.

Generally speaking, rel->tuples is the number of 'raw tuples' on disk,
while rel->rows is the estimated number of tuples after applying
restriction clauses.

In this regard, it seems that get_parameterized_baserel_size() does
not do anything wrong.

I think it might be better to modify set_append_rel_size() to set an
appendrel's tuples to the sum of the tuples from each live child,
rather than to its rows. This would also help us adjust the estimate
for the number of distinct values in estimate_num_groups() for
appendrels using the new formula introduced in 84f9a35e3. There were
discussions as well as a patch for this about one year ago. Please
see [1].

[1] https://postgr.es/m/CAMbWs4-ocromEKMtVDH3RBMuAJQaQDK0qi4k6zOuvpOnMWZauw@mail.gmail.com

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2024-11-26 13:25:56 Re: Auto Vacuum optimisation
Previous Message Ashutosh Bapat 2024-11-26 13:18:38 Re: Separate memory contexts for relcache and catcache