Re: [HACKERS] path toward faster partition pruning

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] path toward faster partition pruning
Date: 2018-04-04 07:04:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018/04/04 14:42, Amit Langote wrote:
> Attached v48.

I had forgotten to remove the static_pruning parameter I had added in the
v47, because it is no longer used. Static pruning now occurs even if a
step contains all Params, in which case each of
get_matching_hash/list/range_bounds() functions returns offsets of all
non-null datums, because the Params cannot be resolved to actual values
during static pruning.

Also, a few changes to get_matching_partitions that David had proposed in
his delta patch but I had failed to include them in v48.

Attached v49.


Attachment Content-Type Size
v49-0001-Add-partsupfunc-to-PartitionSchemeData.patch text/plain 3.4 KB
v49-0002-Add-more-tests-for-partition-pruning.patch text/plain 16.7 KB
v49-0003-Faster-partition-pruning.patch text/plain 122.8 KB
v49-0004-Add-only-unpruned-partitioned-child-rels-to-part.patch text/plain 24.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-04-04 07:06:38 Re: [HACKERS] path toward faster partition pruning
Previous Message David Rowley 2018-04-04 07:04:17 Re: [HACKERS] Runtime Partition Pruning