Re: [HACKERS] path toward faster partition pruning

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

On 2 February 2018 at 23:03, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> 2. PartitionClauseInfo->keyclauses is a list of PartClause which is
>> not a node type. This will cause _copyPartitionClauseInfo() to fail.
>> I'm still not quite sure the best way to fix #2 since PartClause
>> contains a FmgrInfo. I do have a local fix which moves PartClause to
>> primnodes.h and makes it a proper node type. I also added a copy
>> function which does not copy any of the cache fields in PartClause. It
>> just sets valid_cache to false. I didn't particularly think this was
>> the correct fix. I just couldn't think of how exactly this should be
>> done at the time.
>> The attached patch also adds the missing nodetag from
>> PartitionClauseInfo and also fixes up other code so as we don't memset
>> the node memory to zero, as that would destroy the tag. I ended up
>> just having extract_partition_key_clauses do the makeNode call. This
>> also resulted in populate_partition_clauses being renamed to
>> generate_partition_clauses
> I started wondering if it's not such a good idea to make
> PartitionClauseInfo a Node at all? I went back to your earlier message
> [1] where you said that it's put into the Append node for run-time pruning
> to use, but it doesn't sound nice that we'd be putting into the plan
> something that's looks more like scratchpad for the partition.c code. I
> think we should try to keep PartitionClauseInfo in partition.h and put
> only the list of matched bare clauses into Append.

That sounds like a good idea.

A patch which puts this back is attached.

I've changed the run-time prune patch to process the clause lists
during execution instead.

David Rowley
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
make_PartitionClauseInfo_a_nonnode_type.patch application/octet-stream 4.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-02-17 09:39:40 Re: [HACKERS] path toward faster partition pruning
Previous Message Fabien COELHO 2018-02-17 09:20:14 pgbench - allow to specify scale as a size