Horton

Re: Problem with default partition pruning

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

View thread View on postgr.es
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: Langote_Amit_f8@lab.ntt.co.jp
Cc: hosoya.yuzuko@lab.ntt.co.jp, thibaut.madelaine@dalibo.com, imai.yoshikazu@jp.fujitsu.com, pgsql-hackers@lists.postgresql.org
Date: 2019-04-10T03:06:45Z
Lists: pgsql-hackers 
Hi, Amit.

At Wed, 10 Apr 2019 10:48:38 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in <4ef8d47d-b0c7-3093-5aaa-226162c5b59b@lab.ntt.co.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.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Don't constraint-exclude partitioned tables as much

  2. Apply constraint exclusion more generally in partitioning

  3. Improve pruning of a default partition

  4. Doc: Fix event trigger firing table

  5. Remove obsolete nbtree insertion comment.