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
>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.
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=#
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
>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
+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
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
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
> >
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,
>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
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,
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;
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
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
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 @@
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
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,
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
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
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
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
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
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
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
>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
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
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
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 ..
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:
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
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:
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
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
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’
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
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
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
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
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,
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
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
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
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]
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=#
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
>
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
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
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
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
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
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
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
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
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
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
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,
>
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
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
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
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.
>
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
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.
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
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
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
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
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().
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);
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
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
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
>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
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
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
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
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
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
101 - 177 of 177 matches
Mail list logo