Re: Problem with default partition pruning

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
Cc: hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp, thibaut(dot)madelaine(at)dalibo(dot)com, imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Problem with default partition pruning
Date: 2019-04-10 03:06:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi, Amit.

At Wed, 10 Apr 2019 10:48:38 +0900, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote in <4ef8d47d-b0c7-3093-5aaa-226162c5b59b(at)lab(dot)ntt(dot)co(dot)jp>
> > I think this is useful even counting possible degradation, and I
> > believe generate_partition_qual is not called so often.
> I think more commonly used forms of sub-partitioning will use different
> columns at different levels as in the 2nd example. So, although we don't
> call generate_partition_qual() as much as we used to before, even at the
> times we do, we'd encounter this type of sub-partitioning more often and
> the proposed optimization step will end up being futile in more cases than
> the cases in which it would help. Maybe, that was the reason not to try
> too hard in the first place, not the lack of infrastructure as I was saying.

Range partitioning on date could be a common example of
multilevel partitioning, but I agree with you given a premise
that partition qual is not scanned so frequently.


Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-04-10 03:09:21 Re: Enable data checksums by default
Previous Message Michael Paquier 2019-04-10 02:55:31 Re: pgsql: tableam: basic documentation.