Re: What needs to be done for real Partitioning?
От | Tom Lane |
---|---|
Тема | Re: What needs to be done for real Partitioning? |
Дата | |
Msg-id | 18168.1111265368@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | What needs to be done for real Partitioning? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: What needs to be done for real Partitioning?
|
Список | pgsql-performance |
Josh Berkus <josh@agliodbs.com> writes: > -- CREATE TABLE ... WITH PARTITION ON {expression} I'd rather see the partition control stuff as ALTER TABLE commands, not decoration on CREATE TABLE. See the WITH OIDS business we just went through: adding nonstandard decoration to a standard command isn't good. > -- INSERT INTO should automatically create new partitions where necessary > -- DELETE FROM should automatically drop empty partitions I am not sure I agree with either of those, and the reason is that they would turn low-lock operations into high-lock operations. DELETE FROM would be particularly bad. Furthermore, who wants to implement DROP PARTITION as a DELETE FROM? ISTM the whole point of partitioning is to be able to load and unload whole partitions quickly, and having to DELETE all the rows in a partition isn't my idea of quick. > -- setting of WITH PARTITION ON {expression} TABLESPACE should automatically > create a new tablespace for each new partition and its indexes. This is a bad idea. Where are you going to create these automatic tablespaces? What will they be named? Won't this require superuser privileges? And what's the point anyway? > -- It should be possible to create new, empty partitions via a CREATE TABLE > PARTITION OF {table} ON {value} expression. Huh? ISTM this confuses establishment of a table's partition rule with the act of pre-creating empty partitions for not-yet-used ranges of partition keys. Or are you trying to suggest that a table could be partitioned more than one way at a time? If so, how? regards, tom lane
В списке pgsql-performance по дате отправления: