Re: Dynamic Partitioning using Segment Visibility Maps
| От | Zeugswetter Andreas ADI SD |
|---|---|
| Тема | Re: Dynamic Partitioning using Segment Visibility Maps |
| Дата | |
| Msg-id | E1539E0ED7043848906A8FF995BDA57902B622EA@m0143.s-mxs.net обсуждение исходный текст |
| Ответ на | Re: Dynamic Partitioning using Segment Visibility Maps (Simon Riggs <simon@2ndquadrant.com>) |
| Ответы |
Re: Dynamic Partitioning using Segment Visibility Maps
|
| Список | pgsql-hackers |
> I've kept a list of requests for improvement that I can share with you; > I've always been loathe to publish a list of bad points. I think it would help understand the proposal if you also present the shortcomings. When you presented the positive and negative points, the negative list did look intentionally short :-) This imho provokes negative replies, the average hackers that reply are no dummies eighter. Some of the issues I see, with the proposal made so far: - segment boundaries will imho sometimes be too fuzzy for a reasonably short segment describing where clause - fault isolation - huge global indexes (index create/reorg needs to repeatedly sort data that is long static) - unpredictability - when you delete large parts of the table you want that to be instantaneous and cause little work on the db side - partitioning that also partitions the indexes, this is imho a must have for huge non static tables - when the user tweaks segment size this is already declarative - some indexes only needed for recent data (a partial index would need to slide == recreate) The whole subject is imho very interesting, and I expect more feedback after 8.3 is out. I am also in the declarative camp. In my projects the partitioning is the developer/designer's responsibility, and thus all add/drop partition tasks are automated, no dba. Needless to say, all existing declarative implementations lack some of the essential features on the implementation side, e.g.: - use the btree order of partitions in plans that need more than one partition - a useful syntax that allows automatic creation/exclusion of partitions (e.g. each month of a timestamp in one partition)e.g. partition 'hugetable_'||to_char(ts, 'YYYYMM') with extend(ts, year to month) - unique indexes, equally partitioned like table, that don't contain the partitioning column[s] - some lack expression based - some lack instantaneous attach using a prefilled preindexed table - some lack detach - some need separate tablespace per partition Andreas
В списке pgsql-hackers по дате отправления: