Re: Problem with default partition pruning
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, yuzuko <yuzukohosoya@gmail.com>, shawn wang <shawn.wang.pg@gmail.com>, Shawn Wang <shawn.wang@highgo.ca>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-08-09T14:41:34Z
Lists: pgsql-hackers
On 2019-Aug-09, Amit Langote wrote: > Hmm, oops. I think that judgement was a bit too rushed on my part. I > unintentionally ended up making the partition constraint to *always* > be fetched, whereas we don't need it in most cases. I've reverted > that change. Yeah, I was quite confused about this point yesterday while I was trying to make sense of your patches. > RelOptInfo.partition_qual is poorly named in retrospect. > :( It's not set for all partitions, only those that are partitioned > themselves. Oh. Hmm, I think this realization further clarifies things. Since we're only changing this in the master branch anyway, maybe we can find a better name for it. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Don't constraint-exclude partitioned tables as much
- 815ef2f568c7 13.0 landed
-
Apply constraint exclusion more generally in partitioning
- 4e85642d935e 13.0 landed
-
Improve pruning of a default partition
- e3967a16d3a0 11.5 landed
- 86544071484a 12.0 landed
- 489247b0e615 13.0 landed
-
Doc: Fix event trigger firing table
- 44460d7017cd 13.0 cited
-
Remove obsolete nbtree insertion comment.
- 489e431ba56b 12.0 cited