Re: [HACKERS] Declarative partitioning

On 2016/08/10 19:18, Ashutosh Bapat wrote: > FOR VALUE clause of a partition does not allow a constant expression like > (1/5 -1). It gives syntax error > regression=# create table pt1_p1 partition of pt1 for values start (0) end > ((1/5) - 1); > ERROR: syntax error at or near "(" > LINE

Re: [HACKERS] Declarative partitioning

FOR VALUE clause of a partition does not allow a constant expression like (1/5 -1). It gives syntax error regression=# create table pt1_p1 partition of pt1 for values start (0) end ((1/5) - 1); ERROR: syntax error at or near "(" LINE 1: ...pt1_p1 partition of pt1 for values start (0) end

Re: [HACKERS] Declarative partitioning

What strikes me odd about these patches is RelOptInfo has remained unmodified. For a base partitioned table, I would expect it to be marked as partitioned may be indicating the partitioning scheme. Instead of that, I see that the code directly deals with PartitionDesc, PartitionKey which are part

Re: [HACKERS] Declarative partitioning

On 2016/08/09 6:02, Robert Haas wrote: > On Mon, Aug 8, 2016 at 1:40 AM, Amit Langote > wrote: >>> +1, if we could do it. It will need a change in the way Amit's patch stores >>> partitioning scheme in PartitionDesc. >> >> Okay, I will try to implement this in the

Re: [HACKERS] Declarative partitioning

On Mon, Aug 8, 2016 at 1:40 AM, Amit Langote wrote: >> +1, if we could do it. It will need a change in the way Amit's patch stores >> partitioning scheme in PartitionDesc. > > Okay, I will try to implement this in the next version of the patch. > > One thing that

Re: [HACKERS] Declarative partitioning

> IIUC, this seems like a combination of 2 and 3 above: > > So, we have the following list partitions (as read from the catalog) > > Table 1: p1 {'b', 'f'}, p2 {'c', 'd'}, p3 {'a', 'e'} > Table 2: p1 {'c', 'd'}, p2 {'a', 'e'}, p3 {'b', 'f'} > > By applying the method of 3: > > Table 1: p3 {'a',

Re: [HACKERS] Declarative partitioning

On 2016/08/05 21:38, Ashutosh Bapat wrote: >>> Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a >>> list partitioned tables. I am suggesting that we arrange them as >>> ('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row >> (either >>> for comparison or for

Re: [HACKERS] Declarative partitioning

> > > > > Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a > > list partitioned tables. I am suggesting that we arrange them as > > ('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row > (either > > for comparison or for inserting) has value 'c', we will

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 8:10 AM, Ashutosh Bapat wrote: > On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote: >> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat >> wrote: >> > The lists for list partitioned

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote: > On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat > wrote: > > The lists for list partitioned tables are stored as they are specified by > > the user. While searching for a partition to

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat wrote: > The lists for list partitioned tables are stored as they are specified by > the user. While searching for a partition to route tuple to, we compare it > with every list value of every partition. We might do

Re: [HACKERS] Declarative partitioning

The lists for list partitioned tables are stored as they are specified by the user. While searching for a partition to route tuple to, we compare it with every list value of every partition. We might do something better similar to what's been done to range partitions. The list of values for a

Re: [HACKERS] Declarative partitioning

On 2016/07/19 22:53, Ashutosh Bapat wrote: > I am seeing following warning with this set of patches. > gram.y:4734:24: warning: assignment from incompatible pointer type [enabled > by default] Thanks, will fix. Was a copy-paste error. Thanks, Amit -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Declarative partitioning

I am seeing following warning with this set of patches. gram.y:4734:24: warning: assignment from incompatible pointer type [enabled by default] On Tue, Jul 5, 2016 at 10:18 AM, Amit Langote wrote: > On 2016/07/04 21:31, Ashutosh Bapat wrote: > > Hi Amit, > > I

Re: [HACKERS] Declarative partitioning

On 2016/07/04 21:31, Ashutosh Bapat wrote: > Hi Amit, > I observed that the ChangeVarNodes call at line 1229 in > get_relation_constraints() (code below) changes the varno in the cached > copy of partition key expression, which is undesirable. The reason for this > seems to be that the

Re: [HACKERS] Declarative partitioning

Hi Amit, I observed that the ChangeVarNodes call at line 1229 in get_relation_constraints() (code below) changes the varno in the cached copy of partition key expression, which is undesirable. The reason for this seems to be that the RelationGetPartitionCheckQual() returns the copy of partition

Re: [HACKERS] Declarative partitioning

Hi Amit, I tried creating 2-level partitioned table and tried to create simple table using CTAS from the partitioned table. It gives a cache lookup error. Here's the test CREATE TABLE pt1_l (a int, b varchar, c int) PARTITION BY RANGE(a); CREATE TABLE pt1_l_p1 PARTITION OF pt1_l FOR VALUES START

Re: [HACKERS] Declarative partitioning

On 2016/06/21 16:49, Ashutosh Bapat wrote: > Hi Amit, > I tried creating partitioned table by range on an expression like > CREATE TABLE pt1_e (a int, b int, c varchar) PARTITION BY RANGE(a + > b); > ERROR: syntax error at or near > "+" > > LINE 1: ...E pt1_e (a int, b int, c varchar)

Re: [HACKERS] Declarative partitioning

Hi Amit, I tried creating partitioned table by range on an expression like CREATE TABLE pt1_e (a int, b int, c varchar) PARTITION BY RANGE(a + b); ERROR: syntax error at or near "+" LINE 1: ...E pt1_e (a int, b int, c varchar) PARTITION BY RANGE(a + b); But when I try to create partitioned

Re: [HACKERS] Declarative partitioning

0003-... patch does not apply cleanly. It has some conflicts in pg_dump.c. I have tried fixing the conflict in attached patch. On Mon, May 23, 2016 at 3:35 PM, Amit Langote wrote: > > Hi Ildar, > > On 2016/05/21 0:29, Ildar Musin wrote: > > On 20.05.2016 11:37,

Re: [HACKERS] Declarative partitioning

Hi Amit, On 20.05.2016 11:37, Amit Langote wrote: Perhaps you're already aware but may I also suggest looking at how clauses are matched to indexes? For example, consider how match_clauses_to_index() in src/backend/optimizer/path/indxpath.c works. Thanks, I'll take a closer look at it.

Re: [HACKERS] Declarative partitioning

On 2016/05/19 2:48, Tom Lane wrote: > Amit Langote writes: >> On 2016/05/18 2:22, Tom Lane wrote: >>> The two ways that we've dealt with this type of hazard are to copy data >>> out of the relcache before using it; or to give the relcache the >>> responsibility of

Re: [HACKERS] Declarative partitioning

Amit Langote writes: > On 2016/05/18 2:22, Tom Lane wrote: >> The two ways that we've dealt with this type of hazard are to copy data >> out of the relcache before using it; or to give the relcache the >> responsibility of not moving a particular portion of data if

Re: [HACKERS] Declarative partitioning

Hi Amit and all, On 18.05.2016 04:26, Amit Langote wrote: On 2016/05/18 2:22, Tom Lane wrote: The two ways that we've dealt with this type of hazard are to copy data out of the relcache before using it; or to give the relcache the responsibility of not moving a particular portion of data if it

Re: [HACKERS] Declarative partitioning

On 2016/05/18 2:22, Tom Lane wrote: > Amit Langote writes: >> On 2016/05/16 22:12, Ildar Musin wrote: >>> Could you please tell is >>> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE >>> query? > >> Hmm, I think invalidation would not

Re: [HACKERS] Declarative partitioning

Amit Langote writes: > On 2016/05/16 22:12, Ildar Musin wrote: >> Could you please tell is >> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE >> query? > Hmm, I think invalidation would not occur mid-query since it would have > acquired a

Re: [HACKERS] Declarative partitioning

Hi Ildar, On 2016/05/16 22:12, Ildar Musin wrote: > Hi Amit, > > I'm running some experiments based on your infrastructure trying to > optimize SELECT queries. At some point I need to get PartitionDesc for > relation and to do it I'm using RelationGetPartitionDesc() function. > Problem is that

Re: [HACKERS] Declarative partitioning

Hi Amit, I'm running some experiments based on your infrastructure trying to optimize SELECT queries. At some point I need to get PartitionDesc for relation and to do it I'm using RelationGetPartitionDesc() function. Problem is that this function copies relcache data and it can be quite slow

Re: [HACKERS] Declarative partitioning

Hi, On 2016/05/12 17:42, Sameer Thakur-2 wrote: > Hello Amit, > In the example >> create table part201606week4 partition of parted >> for values start (2016, 6, 2) end (2016, 6, 29); > > seems to be a typo Oops, there indeed is. create table part201606week4 partition of parted for values

Re: [HACKERS] Declarative partitioning

Hello Amit, In the example >create table part201606week4 partition of parted >for values start (2016, 6, 2) end (2016, 6, 29); seems to be a typo regards Sameer -- View this message in context: http://postgresql.nabble.com/Declarative-partitioning-tp5862462p5903204.html Sent from the

Re: [HACKERS] Declarative partitioning

Hi Ashutosh, On 2016/05/09 20:21, Ashutosh Bapat wrote: > Hi Amit, > I am trying multi-column/expression partitions. Thanks for the tests. > create table t1_multi_col (a int, b int) partition by range (a, b); > create table t1_mc_p1 partition of t1_multi_col for values start (1, 200) > end

Re: [HACKERS] Declarative partitioning

Hi Amit, I am trying multi-column/expression partitions. create table t1_multi_col (a int, b int) partition by range (a, b); create table t1_mc_p1 partition of t1_multi_col for values start (1, 200) end (100, 300); create table t1_mc_p2 partition of t1_multi_col for values start (200, 1) end

Re: [HACKERS] Declarative partitioning

On 2016-04-15 04:35, Amit Langote wrote: A quick test with: 0001-Add-syntax-to-specify-partition-key-v3.patch 0002-Infrastructure-for-creation-of-partitioned-tables-v3.patch 0003-Add-syntax-to-create-partitions-v3.patch 0004-Infrastructure-for-partition-metadata-storage-and-ma-v3.patch

Re: [HACKERS] Declarative partitioning

Hi Ildar, On Wed, Apr 20, 2016 at 11:46 PM, Ildar Musin wrote: > Thanks for clarification! I tried the updated patch, now it works correctly. Great, thanks! > I encountered another problem that concerns expressions as partitioning key. > Probably there is still some

Re: [HACKERS] Declarative partitioning

Hi Amit, On 20.04.2016 13:28, Amit Langote wrote: On 2016/04/19 23:52, Amit Langote wrote: On Tue, Apr 19, 2016 at 11:26 PM, Alexander Korotkov Another question is that it might be NOT what users expect from that. From the syntax side it very looks like defining something boxes regions for

Re: [HACKERS] Declarative partitioning

Hi Idlar, Alexander, On Tue, Apr 19, 2016 at 11:26 PM, Alexander Korotkov wrote: > On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote: >> >> Thanks for your new patch! I've tried it and discovered some strange >> behavior for partitioning by

Re: [HACKERS] Declarative partitioning

On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote: > On 15.04.2016 07:35, Amit Langote wrote: > >> Thanks a lot for the comments. The patch set changed quite a bit since >> the last version. Once the CF entry was marked returned with feedback on >> March 22, I held off

Re: [HACKERS] Declarative partitioning

Hi Amit, On 15.04.2016 07:35, Amit Langote wrote: Thanks a lot for the comments. The patch set changed quite a bit since the last version. Once the CF entry was marked returned with feedback on March 22, I held off sending the new version at all. Perhaps, it would have been OK. Anyway here it

Re: [HACKERS] Declarative partitioning

On 2016/04/18 15:33, Ashutosh Bapat wrote: >> For time being, I will leave this as yet unaddressed (I am thinking about >> what is reasonable to do for this also considering Robert's comment). Is >> that OK? >> > > Right now EXPLAIN of select * from t1, where t1 is partitioned table shows >

Re: [HACKERS] Declarative partitioning

On Mon, Apr 18, 2016 at 1:23 PM, Amit Langote wrote: > On 2016/04/18 15:38, Ashutosh Bapat wrote: > >> There was no KeyTypeCollInfo in early days of the patch and then I found > >> myself doing a lot of: > >> > >> partexprs_item = list_head(key->partexprs); > >>

Re: [HACKERS] Declarative partitioning

On 2016/04/18 15:38, Ashutosh Bapat wrote: >> There was no KeyTypeCollInfo in early days of the patch and then I found >> myself doing a lot of: >> >> partexprs_item = list_head(key->partexprs); >> for (attr in key->partattrs) >> { >> if (attr->attnum != 0) >> { >> // simple column

Re: [HACKERS] Declarative partitioning

> On 2016/04/15 18:46, Ashutosh Bapat wrote: > > > > 3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be > > obtained by calling functions exprType, exprTypemod on partexprs. Why do > we > > need to store that information as a separate member? > > There was no KeyTypeCollInfo in

Re: [HACKERS] Declarative partitioning

> >> Regarding 6, it seems to me that because Append does not have a > associated > >> relid (like scan nodes have with scanrelid). Maybe we need to either > fix > >> Append or create some enhanced version of Append which would also > support > >> dynamic pruning. > >> > > > > Right, I think,

Re: [HACKERS] Declarative partitioning

On Fri, Apr 15, 2016 at 10:30 PM, Robert Haas wrote: > On Fri, Apr 15, 2016 at 5:46 AM, Ashutosh Bapat > wrote: > > Retaining the partition hierarchy would help to push-down join across > > partition hierarchy effectively. > > -1. You

Re: [HACKERS] Declarative partitioning

Hi, On 2016/04/15 18:46, Ashutosh Bapat wrote: > > 3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be > obtained by calling functions exprType, exprTypemod on partexprs. Why do we > need to store that information as a separate member? There was no KeyTypeCollInfo in early days

Re: [HACKERS] Declarative partitioning

Hi Ashutosh, On 2016/04/15 18:48, Ashutosh Bapat wrote: > With the new set of patches, I am getting following warnings but no > compilation failures. Patches apply smoothly. > partition.c:1216:21: warning: variable ‘form’ set but not used > [-Wunused-but-set-variable] > partition.c:1637:20:

Re: [HACKERS] Declarative partitioning

On Fri, Apr 15, 2016 at 5:46 AM, Ashutosh Bapat wrote: > Retaining the partition hierarchy would help to push-down join across > partition hierarchy effectively. -1. You don't get to insert cruft into the final plan for the convenience of the optimizer. I think

Re: [HACKERS] Declarative partitioning

With the new set of patches, I am getting following warnings but no compilation failures. Patches apply smoothly. partition.c:1216:21: warning: variable ‘form’ set but not used [-Wunused-but-set-variable] partition.c:1637:20: warning: variable ‘form’ set but not used [-Wunused-but-set-variable]

Re: [HACKERS] Declarative partitioning

With the new set of patches, I am getting following warnings but no compilation failures. Patches apply smoothly. partition.c:1216:21: warning: variable ‘form’ set but not used [-Wunused-but-set-variable] partition.c:1637:20: warning: variable ‘form’ set but not used [-Wunused-but-set-variable]

Re: [HACKERS] Declarative partitioning

Hi Amit, Here are some random comments. You said that you were about to post a new patch, so you might have already taken care of those comments. But anyway here they are. 1. Following patches do not apply cleanly for me. 0001 0003 - conflicts at #include for partition.h in rel.h. 0004 -

Re: [HACKERS] Declarative partitioning

On 2016/03/22 4:55, Robert Haas wrote: > So, the last patch on this thread was posted on February 17th, and the > CF entry was marked Waiting on Author on March 2nd. Even if we had a > new patch in hand at this point, I don't think there's any real chance > of being able to get this done for 9.6;

Re: [HACKERS] Declarative partitioning

On 21 March 2016 at 19:55, Robert Haas wrote: > On Wed, Mar 16, 2016 at 10:49 AM, Alexander Korotkov > wrote: > >> > I'd like to validate that this development plan doesn't overlaps with > >> > your > >> > plans. If out plans are not

Re: [HACKERS] Declarative partitioning

On Wed, Mar 16, 2016 at 10:49 AM, Alexander Korotkov wrote: >> > I'd like to validate that this development plan doesn't overlaps with >> > your >> > plans. If out plans are not overlapping then let's accept this plan of >> > work >> > for 9.7. >> >> It looks OK to me.

Re: [HACKERS] Declarative partitioning

Hi Alexander, Thanks a lot for taking a look! On Wed, Mar 16, 2016 at 10:56 PM, Alexander Korotkov wrote: > I tried to apply your patch. It still applies, but has some duplicate oids. Actually, a reworked version I will post hopefully early next week will have fixed

Re: [HACKERS] Declarative partitioning

On Wed, Mar 16, 2016 at 5:29 PM, Amit Langote wrote: > > 9.6 feature freeze in coming, and we're planning our development > resources > > for 9.7. Besides providing an extension, we would like these features to > > eventually arrive to core. In order to achieve this we

Re: [HACKERS] Declarative partitioning

Hi, Amit! I tried to apply your patch. It still applies, but has some duplicate oids. After fixing duplicate oids, I've noticed following warning during compilation by clang-700.1.81. scan.c:10308:23: warning: unused variable 'yyg' [-Wunused-variable] struct yyguts_t * yyg = (struct

Re: [HACKERS] Declarative partitioning

> > > I think we're converging on a good syntax, but I don't think the > choice of nothingness to represent an open range is a good idea, both > because it will probably create grammar conflicts now or later and > also because it actually is sort of confusing and unintuitive to read > given the

Re: [HACKERS] Declarative partitioning

On Fri, Feb 26, 2016 at 1:05 AM, Amit Langote wrote: > I think setting up N ResultRelInfos in advance where the tuple would only > ever require one might be superfluous. But that may point to some flaw in > my original design or thinking about the case. You have a

Re: [HACKERS] Declarative partitioning

On Mon, Mar 7, 2016 at 8:39 PM, Amit Langote wrote: >> Which means your creates would look like (following Robert Haas's implied >> suggestion that we leave off the string literal quotes): >> >> CREATE TABLE foo_ax1x PARTITION OF foo FOR VALUES ( , (b,2) ); >>

Re: [HACKERS] Declarative partitioning

> > > So presently partitions that are unbounded on the lower end aren't > > possible, but that's a creation syntax issue, not an infrastructure > issue. > > Correct? > > In case it wasn't apparent, you can create those: > > FOR VALUES END (upper-bound) [INCLUSIVE] > > which is equivalent to: > >

Re: [HACKERS] Declarative partitioning

Hi, On 2016/03/09 9:17, Corey Huinker wrote: >> >> Sorry for replying so late. > No worries! We have jobs to do aside from this. Thanks! >> Everything seemed to go dandy until I tried FOR VALUES (blah , blah], >> where psql wouldn't send the command string without accepting the closing >>

Re: [HACKERS] Declarative partitioning

> > Sorry for replying so late. > No worries! We have jobs to do aside from this. > > Everything seemed to go dandy until I tried FOR VALUES (blah , blah], > where psql wouldn't send the command string without accepting the closing > parenthesis, :(. So maybe I should try to put the whole

Re: [HACKERS] Declarative partitioning

Hi Corey, Sorry for replying so late. On 2016/02/25 3:31, Corey Huinker wrote: > [ ... ] > So I would assume that we'd use a syntax that presumed the columns were in > a composite range type. > > Which means your creates would look like (following Robert Haas's implied > suggestion that we

Re: [HACKERS] Declarative partitioning

Hi Ildar, On 2016/02/29 7:14, Ildar Musin wrote: > 16/02/16 07:46, Amit Langote wrote: >> On 2016/02/16 11:41, Josh berkus wrote: >>> We're not going to use CE for the new partitioning long-term, are we? This >>> is just the first version, right? >> Yes. My approach in previous versions of

Re: [HACKERS] Declarative partitioning

16/02/16 07:46, Amit Langote wrote: Hi Josh, On 2016/02/16 11:41, Josh berkus wrote: On 02/15/2016 04:28 PM, Amit Langote wrote: Also, you won't see any optimizer and executor changes. Queries will still use the same plans as existing inheritance-based partitioned tables, although as I

Re: [HACKERS] Declarative partitioning

Hi, Thanks for your feedback. On 2016/02/26 0:43, Jean-Pierre Pelletier wrote: > Why not based it on "Exclusion Constraint" ? > > Most discussions as of late seems to focus on Range overlaps which appeal > (I would think) is that it supports both "equality" and "overlaps", two > popular

Re: [HACKERS] Declarative partitioning

On 2016/02/23 22:51, Robert Haas wrote: > On Thu, Feb 18, 2016 at 11:11 AM, Amit Langote wrote: >> Some might think that writing potentially the same PARTITION BY clause 100 >> times for 100 level-1 partitions could be cumbersome. That is what >> SUBPARTITION BY notation may be good as a shorthand

Re: [HACKERS] Declarative partitioning

Why not based it on "Exclusion Constraint" ? Most discussions as of late seems to focus on Range overlaps which appeal (I would think) is that it supports both "equality" and "overlaps", two popular partitioning schemes. "Equality" as in "value1 = value2" can be implemented with "range overlaps"

Re: [HACKERS] Declarative partitioning

Why not based it on "Exclusion Constraint" ? Most discussions as of late seems to focus on Range overlaps which appeal (I would think) is that it supports both "equality" and "overlaps", two popular partitioning schemes. "Equality" as in "value1 = value2" can be implemented with "range overlaps"

Re: [HACKERS] Declarative partitioning

> > Hm, I see. How about multi-column keys? Do we care enough about that use > case? I don't see a nice-enough-looking range literal for such keys. > Consider for instance, > > With the partitioned table defined as: > > CREATE TABLE foo(c1 char(2), c2 char(2)) PARTITION BY RANGE (c1, c2); >

Re: [HACKERS] Declarative partitioning

On 2016/02/20 5:06, Corey Huinker wrote: > On Thu, Feb 18, 2016 at 12:41 AM, Amit Langote wrote: > >> START [ EXCL ] (startval) END [ INCL ] (endval) >> >> That is, in range type notation, '[startval, endval)' is the default >> behavior. So for each partition, there is at least the following

Re: [HACKERS] Declarative partitioning

On Thu, Feb 18, 2016 at 11:11 AM, Amit Langote wrote: >> Personally, I would be more inclined to make this a CREATE TABLE statement, >> like >> >> CREATE TABLE partition_name PARTITION OF parent_name FOR VALUES ... >> CREATE TABLE subpartition_name PARTITION OF

Re: [HACKERS] Declarative partitioning

On Sat, Feb 20, 2016 at 1:41 PM, Peter Eisentraut wrote: > On 2/16/16 9:56 PM, Amit Langote wrote: >> From now on, instead of attaching multiple files like in the previous >> message, I will send a single tar.gz which will contain patches created by >> git-format-patch. > >

Re: [HACKERS] Declarative partitioning

On 2/16/16 9:56 PM, Amit Langote wrote: > From now on, instead of attaching multiple files like in the previous > message, I will send a single tar.gz which will contain patches created by > git-format-patch. Please don't do that. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Declarative partitioning

On Thu, Feb 18, 2016 at 12:41 AM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > START [ EXCL ] (startval) END [ INCL ] (endval) > > That is, in range type notation, '[startval, endval)' is the default > behavior. So for each partition, there is at least the following pieces of >

Re: [HACKERS] Declarative partitioning

On 2016/02/16 21:57, Robert Haas wrote: > On Fri, Jan 15, 2016 at 5:48 AM, Amit Langote > wrote: >> If we have a CREATE statement for each partition, how do we generalize >> that to partitions at different levels? For example, if we use something >> like the

Re: [HACKERS] Declarative partitioning

On 2016/02/15 10:55, Amit Langote wrote: > required. There is also basic planner support but no support yet to enable > constraint exclusion on partitions (which will be fulfilled shortly by > installing equivalent check constraints on partitions). Just to follow up on this - attached now adds

Re: [HACKERS] Declarative partitioning

On Fri, Jan 22, 2016 at 8:54 AM, Tomas Vondra wrote: > I'd like to comment on the one thing and that's the syntax. It seems to me > we're really trying to reinvent the wheel and come up with our own version > of the syntax. Is there a particular reason why not to

Re: [HACKERS] Declarative partitioning

On Fri, Jan 15, 2016 at 5:48 AM, Amit Langote wrote: > If we have a CREATE statement for each partition, how do we generalize > that to partitions at different levels? For example, if we use something > like the following to create a partition of parent_name: > >

Re: [HACKERS] Declarative partitioning

Hi Josh, On 2016/02/16 11:41, Josh berkus wrote: > On 02/15/2016 04:28 PM, Amit Langote wrote: >> Also, you won't see any optimizer and executor changes. Queries will still >> use the same plans as existing inheritance-based partitioned tables, >> although as I mentioned, constraint exclusion

Re: [HACKERS] Declarative partitioning

On 02/15/2016 04:28 PM, Amit Langote wrote: Also, you won't see any optimizer and executor changes. Queries will still use the same plans as existing inheritance-based partitioned tables, although as I mentioned, constraint exclusion won't yet kick in. That will be fixed very shortly. We're

Re: [HACKERS] Declarative partitioning

> > Also, you won't see any optimizer and executor changes. Queries will still > use the same plans as existing inheritance-based partitioned tables, > although as I mentioned, constraint exclusion won't yet kick in. That will > be fixed very shortly. > > And of course, comments on syntax are

Re: [HACKERS] Declarative partitioning

Hi Corey, On 2016/02/16 5:15, Corey Huinker wrote: >> >> The individual patches have commit messages that describe code changes. >> This is registered in the upcoming CF. Feedback and review is greatly >> welcomed! >> > We have a current system that is currently a mix of tables, each of which >

Re: [HACKERS] Declarative partitioning

> > > The individual patches have commit messages that describe code changes. > This is registered in the upcoming CF. Feedback and review is greatly > welcomed! > > Thanks, > Amit > > We have a current system that is currently a mix of tables, each of which is range partitioned into approximately

Re: [HACKERS] Declarative partitioning

Hi Tomas, Thanks for your comments and sorry for replying so late. On 2016/01/22 22:54, Tomas Vondra wrote: > thanks for working on this. Seems the last version of the patch was > submitted more than 2 months ago and I believe large parts of it will get > reworked based on the extensive

Re: [HACKERS] Declarative partitioning

Hi, On 2016/01/23 3:42, Corey Huinker wrote: >> So for now, you create an empty partitioned table specifying all the >> partition keys without being able to define any partitions in the same >> statement. Partitions (and partitions thereof, if any) will be created >> using CREATE PARTITION

Re: [HACKERS] Declarative partitioning

> > > So for now, you create an empty partitioned table specifying all the > partition keys without being able to define any partitions in the same > statement. Partitions (and partitions thereof, if any) will be created > using CREATE PARTITION statements, one for each. > ...and I would assume

Re: [HACKERS] Declarative partitioning

Hi Amit, thanks for working on this. Seems the last version of the patch was submitted more than 2 months ago and I believe large parts of it will get reworked based on the extensive discussion on this list, so I haven't looked at the code at all. I'd like to comment on the one thing and

Re: [HACKERS] Declarative partitioning

Hi, On 2016/01/17 9:47, Corey Huinker wrote: >> If we have a CREATE statement for each partition, how do we generalize >> that to partitions at different levels? For example, if we use something >> like the following to create a partition of parent_name: >> >> CREATE PARTITION partition_name OF

Re: [HACKERS] Declarative partitioning

> > > If we have a CREATE statement for each partition, how do we generalize > that to partitions at different levels? For example, if we use something > like the following to create a partition of parent_name: > > CREATE PARTITION partition_name OF parent_name FOR VALUES ... > WITH ...

Re: [HACKERS] Declarative partitioning

On 2015/12/18 3:56, Robert Haas wrote: > On Mon, Dec 14, 2015 at 2:14 AM, Amit Langote > wrote: >> Syntax to create a partitioned table (up to 2 levels of partitioning): >> >> CREATE TABLE foo ( >> ... >> ) >> PARTITION BY R/L ON (key0) >> SUBPARTITION BY R/L ON

Re: [HACKERS] Declarative partitioning

On Mon, Dec 14, 2015 at 2:14 AM, Amit Langote wrote: > Syntax to create a partitioned table (up to 2 levels of partitioning): > > CREATE TABLE foo ( > ... > ) > PARTITION BY R/L ON (key0) > SUBPARTITION BY R/L ON (key1) > [(PARTITION foo_1 FOR VALUES [] [] >

Re: [HACKERS] Declarative partitioning

On 2015/11/24 2:23, Robert Haas wrote: > To me, it seems like there is a pretty obvious approach here: each > table can be either a plain table, or a partition root (which can look > just like an empty inheritance parent). Then multi-level partitioning > falls right out of that design without

Re: [HACKERS] Declarative partitioning

On Tue, Nov 24, 2015 at 7:03 AM, Robert Haas wrote: > On Mon, Nov 23, 2015 at 1:44 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I support building incrementally, but I don't see why we want to >>> change the catalog structure and then

Re: [HACKERS] Declarative partitioning

On 2015/12/02 15:41, Michael Paquier wrote: > It seems that the consensus is to rework a bit more this patch. > Returned with feedback then? Yes, as far as this commitfest is concerned. Or "moved to the next commitfest"? Not sure exactly which makes sense. Thanks, Amit -- Sent via

Re: [HACKERS] Declarative partitioning

On Wed, Dec 2, 2015 at 3:55 PM, Amit Langote wrote: > On 2015/12/02 15:41, Michael Paquier wrote: >> It seems that the consensus is to rework a bit more this patch. >> Returned with feedback then? > > Yes, as far as this commitfest is concerned. Or "moved to the

Re: [HACKERS] Declarative partitioning

Robert Haas wrote: > I support building incrementally, but I don't see why we want to > change the catalog structure and then change it again. That seems > like it makes the project more work, not less. I agree with what you say. I thought you were saying that the implementation had to provide

Re: [HACKERS] Declarative partitioning

On Mon, Nov 23, 2015 at 1:44 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I support building incrementally, but I don't see why we want to >> change the catalog structure and then change it again. That seems >> like it makes the project more work, not less. > > I

Re: [HACKERS] Declarative partitioning

On Fri, Nov 20, 2015 at 6:44 AM, Alvaro Herrera wrote: > Amit Langote wrote: >> On Fri, Nov 20, 2015 at 7:20 PM, Simon Riggs wrote: >> > Drop it?? I think he means "in this initial patch", right Amit L ? >> >> Yes, there was some notion of

Re: [HACKERS] Declarative partitioning

Amit Langote wrote: > On Fri, Nov 20, 2015 at 7:20 PM, Simon Riggs wrote: > > Drop it?? I think he means "in this initial patch", right Amit L ? > > Yes, there was some notion of multi-level partitioning in the earlier > patch but I removed it from the version I posted on

<    1   2   3   4   5   6   7   8   9   10   >