Syntax for partitioning
in [PgSql]
|
Prev: [HACKERS] pg_read_file() and non-ascii input file
Next: [HACKERS] Proposal - temporal contrib module
From: Simon Riggs on 18 Nov 2009 03:01 On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote: > 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". If we can agree the parts that are required, I would at least be confident that we have understood this enough to allow one part to proceed ahead of the others. For partitioning the parts are these 1. Syntax for explicit partitioning 2. Internal data representations 3. Optimizations many and various 4. Data Routing a) Data routing on INSERT/COPY b) UPDATE handling when the UPDATE causes partition migration If this patch puts forward a solution for (2) also, then it is potentially worthwhile. That is the real blocking point here. Once we have that other people will quickly fill in the later parts. I foresee a data structure that is a sorted list of boundary-values, cached on the parent-relation. This should be accessible to allow bsearch of particular values during both planning and execution. Same rules apply as btree operator classes. For multi-level hierarchies the parent level should have the union of all sub-hierarchies. I think we need an index on pg_inherits also. So please do (1) and (2), not just (1) in isolation. -- Simon Riggs www.2ndQuadrant.com -- 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: Markus Wanner on 19 Nov 2009 09:58 Hi, Robert Haas wrote: > Settling on a syntax, and an internal representation for that syntax, I've been under the impression that this was only about syntax. What are the internal additions? Generally speaking, I'd agree with Simon or even vote for doing the internals first and add the syntactic sugar only later on. > seems like it will make subsequent > discussions about those projects considerably more straightforward, ...or subsequent implementations more complicated, because you have to support an awkward syntax. > and it has some value in and of itself since similar notation is used > by other databases. That point is well taken, but it would be more compelling if it were the same or at least a compatible syntax. Regards Markus Wanner -- 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: Robert Haas on 19 Nov 2009 10:53 On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner <markus(a)bluegap.ch> wrote: > Hi, > > Robert Haas wrote: >> >> Settling on a syntax, and an internal representation for that syntax, > > I've been under the impression that this was only about syntax. What are the > internal additions? I haven't looked at it in detail, but it adds a new pg_partition table. Whether that table is suitably structured for use by the optimizer is not clear to me. > Generally speaking, I'd agree with Simon or even vote for doing the > internals first and add the syntactic sugar only later on. That's not really possible in this case. The internals consist of taking advantage of the fact that we have explicit knowledge of how the partitions are defined vs. just relying on the (slow) constraint exclusion logic. We can't do that unless, in fact, we have that explicit knowledge, and that requires inventing syntax. > That point is well taken, but it would be more compelling if it were the > same or at least a compatible syntax. There's been an effort to make it close, but I haven't followed it in enough detail to know how close. ....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: Peter Eisentraut on 19 Nov 2009 17:33 On ons, 2009-11-18 at 13:52 +0900, Itagaki Takahiro wrote: > > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > Oops, it should be "p"alloc. Thanks. A very low-level comment: 1) Please stop casting the results of palloc and malloc. We are not writing C++ here. 2) I would prefer that you apply sizeof on the variable, not on the type. That way, the expression is independent of any type changes of the variable, and can be reviewed without having to scroll around for the variable definition. So how about, partinfo = palloc(ntups * sizeof(*partinfo)); -- 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: Nikhil Sontakke on 20 Nov 2009 00:44
Hi, >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > 1) Please stop casting the results of palloc and malloc. We are not > writing C++ here. > I thought it was/is a good C programming practice to typecast (void *) always to the returning structure type!! Regards, Nikhils > 2) I would prefer that you apply sizeof on the variable, not on the > type. That way, the expression is independent of any type changes of > the variable, and can be reviewed without having to scroll around for > the variable definition. > > So how about, > > partinfo = palloc(ntups * sizeof(*partinfo)); > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |