From: Amit Kapila [mailto:amit.kapil...@gmail.com] Sent: Friday, December 05, 2014 5:10 PM To: Amit Langote Cc: Jim Nasby; Robert Haas; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg Hackers Subject: Re: [HACKERS] On partitioning
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > From: Amit Kapila [mailto:amit.kapil...@gmail.com] > On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > > > > The more SQL way would be records (composite types). That would make > > > catalog inspection a LOT easier and presumably make it easier to change > > > the > > > partitioning key (I'm assuming ALTER TYPE cascades to stored data). > > > Records > > > are stored internally as tuples; not sure if that would be faster than a > > > List of > > > Consts or a pg_node_tree. Nodes would theoretically allow using things > > > other > > > than Consts, but I suspect that would be a bad idea. > > > > > > > While I couldn’t find an example in system catalogs where a > > record/composite type is used, there are instances of pg_node_tree at a > > number of places like in pg_attrdef and others. Could you please point me > > to such a usage for reference? > > > > > I think you can check the same by manually creating table > > with a user-defined type. > > > Create type typ as (f1 int, f2 text); > > Create table part_tab(c1 int, c2 typ); > > Is there such a custom-defined type used in some system catalog? Just not > sure how one would put together a custom type to use in a system catalog > given the way a system catalog is created. That's my concern but it may not > be valid. > > > I think you are right. I think in this case we need something similar > to column pg_index.indexprs which is of type pg_node_tree(which > seems to be already suggested by Robert). So may be we can proceed > with this type and see if any one else has better idea. One point raised about/against pg_node_tree was the values represented therein would turn out to be too generalized to be used with advantage during planning. But, it seems we could deserialize it in advance back to the internal form (like an array of a struct) as part of the cached relation data. This overhead would only be incurred in case of partitioned tables. Perhaps this is what Robert suggested elsewhere. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
