Re: [HACKERS] Adding support for Default partition in partitioning

On 09.05.2017 09:19, Rahila Syed wrote: +1 for AS DEFAULT syntax if it helps in improving readability specially in following case CREATE TABLE p1 PARTITION OF test AS DEFAULT PARTITION BY LIST(a); Thank you, Rahila Syed On Tue, May 9, 2017 at 1:13 AM, Robert Haas

Re: [HACKERS] Adding support for Default partition in partitioning

>It seems that adding a new partition at the same level as the default >partition will require scanning it or its (leaf) partitions if >partitioned. Consider that p1, pd are partitions of a list-partitioned >table p accepting 1 and everything else, respectively, and pd is further >partitioned.

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/05/10 2:09, Robert Haas wrote: > On Tue, May 9, 2017 at 9:26 AM, Rahila Syed wrote: >>> Hi Rahila, >> >>> I am not able add a new partition if default partition is further >>> partitioned >>> with default partition. >> >>> Consider example below: >> >>> postgres=#

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, May 9, 2017 at 9:26 AM, Rahila Syed wrote: >>Hi Rahila, > >>I am not able add a new partition if default partition is further >> partitioned >>with default partition. > >>Consider example below: > >>postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY

Re: [HACKERS] Adding support for Default partition in partitioning

>Hi Rahila, >I am not able add a new partition if default partition is further partitioned >with default partition. >Consider example below: >postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY LIST (a); >CREATE TABLE >postgres=# CREATE TABLE test_p1 PARTITION OF test FOR VALUES

Re: [HACKERS] Adding support for Default partition in partitioning

+1 for AS DEFAULT syntax if it helps in improving readability specially in following case CREATE TABLE p1 PARTITION OF test AS DEFAULT PARTITION BY LIST(a); Thank you, Rahila Syed On Tue, May 9, 2017 at 1:13 AM, Robert Haas wrote: > On Thu, May 4, 2017 at 4:40 PM, Sven

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, May 4, 2017 at 4:40 PM, Sven R. Kunze wrote: > It yields > > CREATE TABLE p1 PARTITION OF test DEFAULT PARTITION BY LIST(b); > > This reads to me like "DEFAULT PARTITION". > > I can imagine a lot of confusion when those queries are encountered in the > wild. I know this

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Robert, Thanks for your explnation. On Mon, May 8, 2017 at 9:56 PM, Robert Haas wrote: > On Thu, May 4, 2017 at 4:28 PM, Jeevan Ladhe > wrote: > > While reviewing the code I was trying to explore more cases, and I here > > comes an > >

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, May 4, 2017 at 4:28 PM, Jeevan Ladhe wrote: > While reviewing the code I was trying to explore more cases, and I here > comes an > open question to my mind: > should we allow the default partition table to be partitioned further? I think yes. In general,

Re: [HACKERS] Adding support for Default partition in partitioning

>I am not able add a new partition if default partition is further partitioned >with default partition. Thanks for reporting. I will fix this. >pg_restore is failing for default partition, dump file still storing old syntax of default partition. Thanks for reporting . I will fix this once the

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, I am not able add a new partition if default partition is further partitioned with default partition. Consider example below: postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY LIST (a); CREATE TABLE postgres=# CREATE TABLE test_p1 PARTITION OF test FOR VALUES IN(4, 5,

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, pg_restore is failing for default partition, dump file still storing old syntax of default partition. create table lpd (a int, b int, c varchar) partition by list(a); create table lpd_d partition of lpd DEFAULT; create database bkp owner 'edb'; grant all on DATABASE bkp to edb;

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, still thinking about the syntax (sorry): On 04.05.2017 13:44, Rahila Syed wrote: [...] The syntax implemented in this patch is as follows, CREATE TABLE p11 PARTITION OF p1 DEFAULT; Rewriting the following: On Thu, May 4, 2017 at 4:02 PM, amul sul

Re: [HACKERS] Adding support for Default partition in partitioning

While reviewing the code I was trying to explore more cases, and I here comes an open question to my mind: should we allow the default partition table to be partitioned further? If we allow it(as in the current case) then observe following case, where I have defined a default partitioned which is

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, I have started reviewing your latest patch, and here are my initial comments: 1. In following block, we can just do with def_index, and we do not need found_def flag. We can check if def_index is -1 or not to decide if default partition is present. @@ -166,6 +172,8 @@

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, May 4, 2017 at 5:14 PM, Rahila Syed wrote: > The syntax implemented in this patch is as follows, > > CREATE TABLE p11 PARTITION OF p1 DEFAULT; > > Applied v9 patches, table description still showing old pattern of default partition. Is it expected? create table

Re: [HACKERS] Adding support for Default partition in partitioning

Hello Amul, Thanks for reporting. Please find attached an updated patch which fixes the above. Also, the attached patch includes changes in syntax proposed upthread. The syntax implemented in this patch is as follows, CREATE TABLE p11 PARTITION OF p1 DEFAULT; Thank you, Rahila Syed On Thu,

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, May 2, 2017 at 9:33 PM, Rahila Syed wrote: > Please find attached updated patch with review comments by Robert and Jeevan > implemented. > Patch v8 got clean apply on latest head but server got crash at data insert in the following test: -- Create test table

Re: [HACKERS] Adding support for Default partition in partitioning

Please find attached updated patch with review comments by Robert and Jeevan implemented. The newly proposed syntax CREATE TABLE .. PARTITION OF .. DEFAULT has got most votes on this thread. If there is no more objection, I will go ahead and include that in the patch. Thank you, Rahila Syed On

Re: [HACKERS] Adding support for Default partition in partitioning

On 27.04.2017 22:21, Robert Haas wrote: On Thu, Apr 27, 2017 at 3:15 PM, Sven R. Kunze wrote: Just to make sound a little rounder: CREATE TABLE ... PARTITION OF ... AS DEFAULT CREATE TABLE ... PARTITION OF ... AS FALLBACK or CREATE TABLE ... PARTITION OF ... AS DEFAULT

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 27, 2017 at 3:15 PM, Sven R. Kunze wrote: > On 27.04.2017 15:07, Robert Haas wrote: >> On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed >> wrote: >>> >>> +1 for CREATE TABLE..PARTITION OF...DEFAULT syntax. >>> I think substituting DEFAULT for FOR

Re: [HACKERS] Adding support for Default partition in partitioning

Hi, On Apr 27, 2017 18:37, "Robert Haas" wrote: > > > Are you also working on extending this to work with range > partitioning? Because I think that would be good to do. > > > Currently I am working on review comments and bug fixes for the default list partitioning

Re: [HACKERS] Adding support for Default partition in partitioning

On 27.04.2017 15:07, Robert Haas wrote: On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed wrote: +1 for CREATE TABLE..PARTITION OF...DEFAULT syntax. I think substituting DEFAULT for FOR VALUES is appropriate as both cases are mutually exclusive. Just to make sound a little

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 27, 2017 at 8:49 AM, Rahila Syed wrote: >>I suspect it could be done as of now, but I'm a little worried that it >>might create grammar conflicts in the future as we extend the syntax >>further. If we use CREATE TABLE ... PARTITION OF .. DEFAULT, then the

Re: [HACKERS] Adding support for Default partition in partitioning

>I suspect it could be done as of now, but I'm a little worried that it >might create grammar conflicts in the future as we extend the syntax >further. If we use CREATE TABLE ... PARTITION OF .. DEFAULT, then the >word DEFAULT appears in the same position where we'd normally have FOR >VALUES, and

Re: [HACKERS] Adding support for Default partition in partitioning

Hello Jeevan, Thank you for comments. I will include your comments in the updated patch. >7.The output of describe needs to be improved. The syntax for DEFAULT partitioning is still under discussion. This comment wont be applicable if the syntax is changed. >6. >I am wondering, isn't it

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, Apr 25, 2017 at 11:23 PM, Robert Haas wrote: > On Tue, Apr 25, 2017 at 1:20 AM, Ashutosh Bapat > wrote: >>> I suspect it could be done as of now, but I'm a little worried that it >>> might create grammar conflicts in the future as

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, Apr 25, 2017 at 1:20 AM, Ashutosh Bapat wrote: >> I suspect it could be done as of now, but I'm a little worried that it >> might create grammar conflicts in the future as we extend the syntax >> further. If we use CREATE TABLE ... PARTITION OF ..

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/25 14:20, Ashutosh Bapat wrote: > On Tue, Apr 25, 2017 at 1:46 AM, Robert Haas wrote: >> On Mon, Apr 24, 2017 at 8:14 AM, Ashutosh Bapat >> wrote: >>> On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas wrote:

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, Apr 25, 2017 at 1:46 AM, Robert Haas wrote: > On Mon, Apr 24, 2017 at 8:14 AM, Ashutosh Bapat > wrote: >> On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas wrote: >>> On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/25 5:16, Robert Haas wrote: > On Mon, Apr 24, 2017 at 8:14 AM, Ashutosh Bapat > wrote: >> On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas wrote: >>> On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed wrote:

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Apr 24, 2017 at 8:14 AM, Ashutosh Bapat wrote: > On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas wrote: >> On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed wrote: >>> Following can also be considered as it

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Apr 24, 2017 at 5:44 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas > wrote: > > On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed > wrote: > >> Following can also be considered as it

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, I tried to go through your v7 patch, and following are my comments: 1. With -Werrors I see following compilation failure: parse_utilcmd.c: In function ‘transformPartitionBound’: parse_utilcmd.c:3309:4: error: implicit declaration of function ‘isDefaultPartitionBound’

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Apr 24, 2017 at 4:24 PM, Robert Haas wrote: > On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed wrote: >> Following can also be considered as it specifies more clearly that the >> partition holds default values. >> >> CREATE TABLE ...PARTITION

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Apr 24, 2017 at 5:10 AM, Rahila Syed wrote: > Following can also be considered as it specifies more clearly that the > partition holds default values. > > CREATE TABLE ...PARTITION OF...FOR VALUES DEFAULT; Yes, that could be done. But I don't think it's correct

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Thank you for reviewing. >But that's not a good idea for several reasons. For one thing, you >can also write FOR VALUES IN (DEFAULT, 5) or which isn't sensible. >For another thing, this kind of syntax won't generalize to range >partitioning, which we've talked about making this feature

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 6, 2017 at 7:30 AM, Rahila Syed wrote: > Thanks a lot for testing and reporting this. Please find attached an updated > patch with the fix. The patch also contains a fix > regarding operator used at the time of creating expression as default > partition

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 6, 2017 at 1:17 AM, Rushabh Lathia wrote: > I like the idea about having DEFAULT partition for the range partition. With > the > way partition is designed it can have holes into range partition. I think > DEFAULT > for the range partition is a good idea,

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, Apr 11, 2017 at 9:41 AM, Jeevan Ladhe wrote: > I have checked for NULLs too, and the default partition can be created even > when there are partitions for each TRUE, FALSE and NULL. > > Consider the example below: > > postgres=# CREATE TABLE list_partitioned

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Ashutosh, On Tue, Apr 11, 2017 at 6:02 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Mon, Apr 10, 2017 at 8:12 PM, Jeevan Ladhe > wrote: > > Hi Rahila, > > > > > > With your latest patch: > > > > Consider a case when a table is partitioned

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Apr 10, 2017 at 8:12 PM, Jeevan Ladhe wrote: > Hi Rahila, > > > With your latest patch: > > Consider a case when a table is partitioned on a boolean key. > > Even when there are existing separate partitions for 'true' and > > 'false', still default partition

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, I tried to review the code, and here are some of my early comments: 1. When I configure using "-Werror", I see unused variable in function DefineRelation: tablecmds.c: In function ‘DefineRelation’: tablecmds.c:761:17: error: unused variable ‘partdesc’ [-Werror=unused-variable]

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, With your latest patch: Consider a case when a table is partitioned on a boolean key. Even when there are existing separate partitions for 'true' and 'false', still default partition can be created. I think this should not be allowed. Consider following case: postgres=#

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 6, 2017 at 7:30 AM, Rahila Syed wrote: > Hello, > > Thanks a lot for testing and reporting this. Please find attached an > updated patch with the fix. The patch also contains a fix > regarding operator used at the time of creating expression as default >

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Apr 6, 2017 at 1:18 AM, Amit Langote wrote: > On 2017/04/06 13:08, Keith Fiske wrote: > > On Wed, Apr 5, 2017 at 2:51 PM, Keith Fiske wrote: > >> Only issue I see with this, and I'm not sure if it is an issue, is what > >> happens to that default constraint

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Thanks a lot for testing and reporting this. Please find attached an updated patch with the fix. The patch also contains a fix regarding operator used at the time of creating expression as default partition constraint. This was notified offlist by Amit Langote. Thank you, Rahila Syed On

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/06 13:08, Keith Fiske wrote: > On Wed, Apr 5, 2017 at 2:51 PM, Keith Fiske wrote: >> Only issue I see with this, and I'm not sure if it is an issue, is what >> happens to that default constraint clause when 1000s of partitions start >> getting added? From what I gather the default's

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/06 0:19, Robert Haas wrote: > On Wed, Apr 5, 2017 at 5:57 AM, Rahila Syed wrote: >>> Could you briefly elaborate why you think the lack global index support >>> would be a problem in this regard? >> I think following can happen if we allow rows satisfying the

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Apr 5, 2017 at 2:51 PM, Keith Fiske wrote: > > > Only issue I see with this, and I'm not sure if it is an issue, is what > happens to that default constraint clause when 1000s of partitions start > getting added? From what I gather the default's constraint is built

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/06 0:19, Robert Haas wrote: > On Wed, Apr 5, 2017 at 5:57 AM, Rahila Syed wrote: >>> Could you briefly elaborate why you think the lack global index support >>> would be a problem in this regard? >> I think following can happen if we allow rows satisfying the

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Apr 5, 2017 at 11:19 AM, Robert Haas wrote: > On Wed, Apr 5, 2017 at 5:57 AM, Rahila Syed > wrote: > >>Could you briefly elaborate why you think the lack global index support > >>would be a problem in this regard? > > I think following can

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Apr 5, 2017 at 5:57 AM, Rahila Syed wrote: >>Could you briefly elaborate why you think the lack global index support >>would be a problem in this regard? > I think following can happen if we allow rows satisfying the new partition > to lie around in the > default

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, On 2017/04/05 18:57, Rahila Syed wrote: > Hello Amit, > >> Could you briefly elaborate why you think the lack global index support >> would be a problem in this regard? > I think following can happen if we allow rows satisfying the new partition > to lie around in the > default

Re: [HACKERS] Adding support for Default partition in partitioning

Hello Amit, >Could you briefly elaborate why you think the lack global index support >would be a problem in this regard? I think following can happen if we allow rows satisfying the new partition to lie around in the default partition until background process moves it. Consider a scenario where

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/05 14:41, Rushabh Lathia wrote: > I agree about the future plan about the row movement, how that is I am > not quite sure at this stage. > > I was thinking that CREATE new partition is the DDL command, so even > if row-movement works with holding the lock on the new partition table, >

Re: [HACKERS] Adding support for Default partition in partitioning

Hi, >However, running your original example, I'm getting this error Thank you for testing. Please find attached an updated patch which fixes the above. Thank you, Rahila Syed default_partition_v5.patch Description: application/download -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Apr 5, 2017 at 10:59 AM, Amit Langote wrote: > On 2017/04/05 6:22, Keith Fiske wrote: > > On Tue, Apr 4, 2017 at 9:30 AM, Rahila Syed wrote: > >> Please find attached an updated patch. > >> Following has been accomplished in this update: > >> > >> 1. A new

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/04/05 6:22, Keith Fiske wrote: > On Tue, Apr 4, 2017 at 9:30 AM, Rahila Syed wrote: >> Please find attached an updated patch. >> Following has been accomplished in this update: >> >> 1. A new partition can be added after default partition if there are no >> conflicting rows in default

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, Apr 4, 2017 at 9:30 AM, Rahila Syed wrote: > Hello, > > Please find attached an updated patch. > Following has been accomplished in this update: > > 1. A new partition can be added after default partition if there are no > conflicting rows in default partition. >

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Please find attached an updated patch. Following has been accomplished in this update: 1. A new partition can be added after default partition if there are no conflicting rows in default partition. 2. Solved the crash reported earlier. Thank you, Rahila Syed On Tue, Apr 4, 2017 at

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/31/17 10:45 AM, David Steele wrote: > On 3/29/17 8:13 AM, Rahila Syed wrote: > >> Thanks for reporting. I have identified the problem and have a fix. >> Currently working on allowing >> adding a partition after default partition if the default partition does >> not have any conflicting rows.

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/29/17 8:13 AM, Rahila Syed wrote: Thanks for reporting. I have identified the problem and have a fix. Currently working on allowing adding a partition after default partition if the default partition does not have any conflicting rows. Will update the patch with both of these. The CF has

Re: [HACKERS] Adding support for Default partition in partitioning

Thanks for reporting. I have identified the problem and have a fix. Currently working on allowing adding a partition after default partition if the default partition does not have any conflicting rows. Will update the patch with both of these. Thank you, Rahila Syed On Mon, Mar 27, 2017 at 12:10

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Rahila, IIUC, your default_partition_v3.patch is trying to implement an error if new partition is added to a table already having a default partition. I too tried to run the test and similar to Rushabh, I see the server is crashing with the given test. However, if I reverse the order of

Re: [HACKERS] Adding support for Default partition in partitioning

I applied the patch and was trying to perform some testing, but its ending up with server crash with the test shared by you in your starting mail: postgres=# CREATE TABLE list_partitioned ( postgres(# a int postgres(# ) PARTITION BY LIST (a); CREATE TABLE postgres=# postgres=# CREATE TABLE

Re: [HACKERS] Adding support for Default partition in partitioning

Hello Rushabh, Thank you for reviewing. Have addressed all your comments in the attached patch. The attached patch currently throws an error if a new partition is added after default partition. >Rather then adding check for default here, I think this should be handle inside >get_qual_for_list().

Re: [HACKERS] Adding support for Default partition in partitioning

I picked this for review and noticed that patch is not getting cleanly complied on my environment. partition.c: In function ‘RelationBuildPartitionDesc’: partition.c:269:6: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] Const*val = lfirst(c);

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Please find attached a rebased patch with support for pg_dump. I am working on the patch to handle adding a new partition after a default partition by throwing an error if conflicting rows exist in default partition and adding the partition successfully otherwise. Will post an updated

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Mar 10, 2017 at 2:17 PM, Peter Eisentraut wrote: > On 3/2/17 21:40, Robert Haas wrote: >> On the point mentioned above, I >> don't think adding a partition should move tuples, necessarily; seems >> like it would be good enough - maybe better - for it to

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/2/17 21:40, Robert Haas wrote: > On the point mentioned above, I > don't think adding a partition should move tuples, necessarily; seems > like it would be good enough - maybe better - for it to fail if there > are any that would need to be moved. ISTM that the uses cases of various

Re: [HACKERS] Adding support for Default partition in partitioning

>I agree that adding a new partition should not move any data out of the default. It's easy enough to set up a monitor to watch for data existing in the >default. Perhaps also adding a column to pg_partitioned_table that contains the oid of the default partition so it's easier to identify from a

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/7/17 10:30 AM, Keith Fiske wrote: I'm all for this feature and had suggested it back in the original FWIW, I was working with a system just today that has an overflow partition. thread to add partitioning to 10. I agree that adding a new partition should not move any data out of the

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, Mar 2, 2017 at 9:40 PM, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed > wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Mar 03, 2017 at 08:10:52AM +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from existing default

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote: > 3. Handling adding a new partition to a partitioned table >with default partition. >This will require moving tuples from existing default partition to > newly created partition if they satisfy its partition

[HACKERS] Adding support for Default partition in partitioning

Hello, Currently inserting the data into a partitioned table that does not fit into any of its partitions is not allowed. The attached patch provides a capability to add a default partition to a list partitioned table as follows. postgres=# CREATE TABLE list_partitioned ( a int ) PARTITION

<    1   2