What needs to be done for real Partitioning?
От | Josh Berkus |
---|---|
Тема | What needs to be done for real Partitioning? |
Дата | |
Msg-id | 200503191202.38089.josh@agliodbs.com обсуждение исходный текст |
Ответы |
Re: What needs to be done for real Partitioning?
Re: What needs to be done for real Partitioning? Re: What needs to be done for real Partitioning? Re: What needs to be done for real Partitioning? Re: What needs to be done for real Partitioning? Re: What needs to be done for real Partitioning? |
Список | pgsql-performance |
Folks, I may (or may not) soon have funding for implementing full table partitioning in PostgreSQL. I thought it would be a good idea to discuss with people here who are already using pseudo-partitioning what things need to be added to Postgresql in order to make full paritioning a reality; that is, what do other databases do that we don't? Implementations are seperated into phases I and II, II being harder-and-optional-stuff that may get done later, I being essential features. Ph. I -- CREATE TABLE ... WITH PARTITION ON {expression} ---- should automatically create expression index on {expression} -- INSERT INTO should automatically create new partitions where necessary ---- new tables should automatically inherit all constraints, indexes, keys of "parent" table -- UPDATE should automatically move rows between partitions where applicable -- Query Planner/Executor should be improved to not always materialize paritioned tables used in subqueries and joins. Ph. II -- Foreign Keys to/from partitioned tables should become possible -- Query Planner/Executor should be improved to only join partitions which are compliant with the query's WHERE or JOIN clauses where reasonable -- DELETE FROM should automatically drop empty partitions -- setting of WITH PARTITION ON {expression} TABLESPACE should automatically create a new tablespace for each new partition and its indexes. -- It should be possible to create new, empty partitions via a CREATE TABLE PARTITION OF {table} ON {value} expression. All syntax above is, of course, highly debatable. -- Josh Berkus Aglio Database Solutions San Francisco
В списке pgsql-performance по дате отправления: