Syntax for partitioning
in [PgSql]
|
Prev: [HACKERS] pg_read_file() and non-ascii input file
Next: [HACKERS] Proposal - temporal contrib module
From: Robert Haas on 17 Nov 2009 20:12 On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote: > >> I think syntax support is a good start. > > I don't see a syntax-only patch as being any use at all to this > community. > > We go to enormous lengths in other areas to never allow patches with > restrictions. Why would we allow a patch that is essentially 100% > restriction? i.e. It does nothing at all. Worse than that, it will > encourage people to believe it exists in full, when that isn't the case. > > The syntax has never really been in question, so it doesn't really move > us forwards in any direction. This is exactly the kind of shallow > feature we have always shied away from and that other databases have > encouraged. > > The only reason I can see is that it allows people to develop non-open > source code that matches how Postgres will work when we get our act > together. That seems likely to discourage, rather than encourage the > funding of this work for open source. It may even muddy the water for > people that don't understand that the real magic happens in the > internals, not in the syntax. > > Why not just wait until we have a whole patch and then apply? Because big patches are really hard to get applied. Personally, I think a syntax-only patch makes a lot of sense, as long as the design is carefully thought about so that it can serve as a foundation for future work in this area. I don't think "the whole patch" is even necessarily a well-defined concept in this instance: different people could have very different ideas about what would constitute a complete solution, or which aspects of a complete solution are most important or should be pursued first. Settling on a syntax, and an internal representation for that syntax, seems like it will make subsequent discussions about those projects considerably more straightforward, and it has some value in and of itself since similar notation is used by other databases. At least, that's MHO. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 17 Nov 2009 23:17 Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi> wrote: > Jaime Casanova wrote: > >> PARTITION name VALUES LESS THAN { range_upper | MAXVALUE } > >> | PARTITION name VALUES IN ( list_value [,...] | DEFAULT ) > > > > i remember someone making a comment about actually using operators > > instead of LESS THEN and family > > That doesn't sound like a bad idea.. I prefer to use widely-used syntax instead of postgres original one. Oracle and MySQL already use "LESS THAN" and "IN" for partitioning. I assume almost all user only use the default operators. I don't want to break de facto standard for small utilization area. I think truly what we want is a new partition "kind" in addition to RANGE and LIST. If we want to split geometric data into paritions, we need to treat the the partition key with gist-list operation. I agree with a plan to add some additional parition kinds, but want to keep RANGE and LIST partitions in the current syntax. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 17 Nov 2009 23:24 Simon Riggs <simon(a)2ndQuadrant.com> wrote: > Why not just wait until we have a whole patch and then apply? "A whole patch" can be written by many contributers instead of only one person, no? I think we need to split works for partitioning into serveral parts to encourage developing it. I just did one of the parts, "syntax". Anothe patch "Partitioning option for COPY" will do a good job in the field of "INSERT". Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 17 Nov 2009 23:36 Jaime Casanova <jcasanov(a)systemguards.com.ec> wrote: > > * If a table with the same name already exists when a partition > > is created, the table is re-used as partition. This behavior > > is required for pg_dump to be simple. > > i guess the table must be empty, if not we should be throw an error... > and i actually prefer some more explicit syntax for this not just > reusing a table Yeah, an explicit syntax is better. I've researched other syntax, but I cannot find any good ones. * ALTER TABLE child INHERIT parent AS PARTITION => implemenation "PARTITION is an INHERIT" is revealed to user. * ALTER PARTITION child ATTACH TO parent => child is not a partition yet at that point. * ALTER TABLE parent ADD PARTITION child => "partition" need to be a full-reserved word. Are there better idea? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Itagaki Takahiro on 17 Nov 2009 23:52
Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi> wrote: > this looks like a mistake: > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); Oops, it should be "p"alloc. Thanks. > Maybe we should use something like > PARTITION bar VALUES OPERATOR 0 > when the user specifies the operator? I think we could have reasonable restrictions to the operator for future optimization. Is the VALUES OPERATOR syntax too freedom? For the same reason, USING operator also might be too freedom. RANGE (and maybe also LIST) partition keys should be sortable, operator class name might be better to the option instead of any operators. i.e., PARTITION BY RANGE ( foo [ USING operator ] ) should be: PARTITION BY RANGE ( foo [ btree_ops_name ] ) If we do so, there will be no inconsistency in LESS THAN syntax because btree_ops always have < operator. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
