Re: On partitioning
От | Amit Langote |
---|---|
Тема | Re: On partitioning |
Дата | |
Msg-id | 032601d00471$ea6f4280$bf4dc780$@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: On partitioning (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: On partitioning
|
Список | pgsql-hackers |
Robert, > > I thought putting the partition boundaries into pg_inherits was a > strange choice. I'd put it in pg_class, or in pg_partition if we > decide to create that. Hmm, yeah I guess we are better off using pg_inherits for just saying that a partition is an inheritance child. Other detailsshould go elsewhere for sure. > Maybe as anyarray, but I think pg_node_tree > might even be better. That can also represent data of some arbitrary > type, but it doesn't enforce that everything is uniform. So you could > have a list of objects of the form {RANGEPARTITION :lessthan {CONST > ...} :partition 16982} or similar. The relcache could load that up > and convert the list to a C array, which would then be easy to > binary-search. > > As you say, you also need to store the relevant operator somewhere, > and the fact that it's a range partition rather than list or hash, > say. > I'm wondering here if it's better to keep partition values per partition wherein we have two catalogs, say, pg_partitioned_reland pg_partition_def. pg_partitioned_rel stores information like partition kind, key (attribute number(s)?), key opclass(es). Optionally, we couldalso say here if a given record (in pg_partitioned_rel) represents an actual top-level partitioned table or a partitionthat is sub-partitioned (wherein this record is just a dummy for keys of sub-partitioning and such); something likepartisdummy... pg_partition_def stores information of individual partitions (/sub-partitions, too?) such as its parent (either an actualtop level partitioned table or a sub-partitioning template), whether this is an overflow/default partition, and partitionvalues. Such a scheme would be similar to what Greenplum [1] has. Perhaps this duplicates inheritance and can be argued in that sense, though. Do you think keeping partition defining values with the top-level partitioned table would make some partitioning schemes(multikey, sub- , etc.) a bit complicated to implement? I cannot offhand imagine the actual implementation difficultiesthat might be involved myself but perhaps you have a better idea of such details and would have a say... Thanks, Amit [1] http://gpdb.docs.pivotal.io/4330/index.html#ref_guide/system_catalogs/pg_partition_rule.html http://gpdb.docs.pivotal.io/4330/index.html#ref_guide/system_catalogs/pg_partition.html
В списке pgsql-hackers по дате отправления: