From: | "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Gavin Sherry" <swm(at)alcove(dot)com(dot)au> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dynamic Partitioning using Segment Visibility Maps |
Date: | 2008-01-11 16:31:14 |
Message-ID: | E1539E0ED7043848906A8FF995BDA57902B622EA@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-01-11 17:27:01 | Re: scan.l: check_escape_warning() |
Previous Message | Simon Riggs | 2008-01-11 16:15:06 | Transaction Snapshot Cloning |