Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Rajkumar Raghuwanshi
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CAKcux6nQLSnYs1syFs-MCQaj38N7oEmroK3U6od-1q6uXSRHzw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] path toward faster partition pruning
List pgsql-hackers

On Thu, Oct 19, 2017 at 12:16 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
Description of the attached patches:

0001: add new tests for partition-pruning

0002: patch that makes all the changes needed in the planer (adds a stub
      function in partition.c)

0003: patch that implements the aforementioned stub (significant amount of
      code to analyze partition clauses and gin up bounding keys to
      compare with the values in PartitionBoundInfo; the actual function
      that will do the comparison is just a stub as of this patch)

0004: make some preparatory changes to partition_bound_cmp/bsearch, to be
      able to pass incomplete partition keys (aka, prefix of a multi-
      column key) for comparison with the values in PartitionBoundInfo
     (just a refactoring patch)

0005: implements the stub mentioned in 0003 and finally gets the new
      partition-pruning working (also disables constraint exclusion using
      internal partition constraints by teaching get_relation_constraints
      to not include those).

Feedback greatly welcome.
Hi Amit,

I have tried to apply attached patch. patch applied cleanly on commit id - bf54c0f05c0a58db17627724a83e1b6d4ec2712c
but make failed with below error.
 
./../../../src/include/nodes/relation.h:2126: error: redefinition of typedef ‘AppendRelInfo’
../../../../src/include/nodes/relation.h:584: note: previous declaration of ‘AppendRelInfo’ was here
make[4]: *** [gistbuild.o] Error 1

 

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] How to determine that a TransactionId is really aborted?