Re: [HACKERS] Adding support for Default partition in partitioning - Mailing list pgsql-hackers

From Jeevan Ladhe
Subject Re: [HACKERS] Adding support for Default partition in partitioning
Date
Msg-id CAOgcT0NoHHL6cDpF-iO9xMTzmh3+FVepU_9Yr5e3ohoCxqpdrw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Adding support for Default partition in partitioning  (Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>)
Responses Re: [HACKERS] Adding support for Default partition in partitioning
List pgsql-hackers
Hi,

On Thu, Jul 13, 2017 at 1:01 AM, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com> wrote:
Hi,

I have worked further on V21 patch set, rebased it on latest master commit,
addressed the comments given by Robert, Ashutosh and others.

The attached tar has a series of 7 patches.
Here is a brief of these 7 patches:

0001:
Refactoring existing ATExecAttachPartition  code so that it can be used for
default partitioning as well

0002:
This patch teaches the partitioning code to handle the NIL returned by
get_qual_for_list().
This is needed because a default partition will not have any constraints in case
it is the only partition of its parent.

0003:
Support for default partition with the restriction of preventing addition of any
new partition after default partition.

0004:
Store the default partition OID in pg_partition_table, this will help us to
retrieve the OID of default relation when we don't have the relation cache
available. This was also suggested by Amit Langote here[1].

0005:
Extend default partitioning support to allow addition of new partitions.

0006:
Extend default partitioning validation code to reuse the refactored code in
patch 0001. 

0007:
This patch introduces code to check if the scanning of default partition child
can be skipped if it's constraints are proven.

TODO:
Add documentation.

I have added a documentation patch(patch 0008) to the existing set of patches.
PFA.
 
Merge default range partitioning patch.
 
Beena has created a patch on top of my patches here[1].


Regards,
Jeevan Ladhe
Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: [HACKERS] pg_upgrade failed if view is based on sequence
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy