From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
Subject: | Re: Named vs Unnamed Partitions |
Date: | 2008-01-09 17:04:10 |
Message-ID: | 4784FE8A.603@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Simon Riggs wrote:
> When I delete all rows WHERE some_date < 'cut-off date' on a segment
> boundary value that would delete all segments that met the criteria. The
> following VACUUM will then return those segments to be read-write, where
> they can then be refilled with new incoming data. The only command we
> would have to run is the DELETE, everything else is automatic.
Agreed, that would be very nice.
> So not convinced of the need for named sections of tables yet. It all
> seems like detail, rather than actually what we want for managing large
> tables.
What do you think about letting the database system know the split point
vs it having to find optimal split points automatically?
Read-write vs. read-only is as good start, but can that concept be
expanded to automatically choosing hash partitioning between storage
systems, for example? Or more generally: can the database system gather
enough information about the storage systems to take a decision as good
as or better than the DBA?
Regards
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-01-09 17:06:15 | Re: Named vs Unnamed Partitions |
Previous Message | Gregory Stark | 2008-01-09 16:47:51 | Re: OUTER JOIN performance regression remains in 8.3beta4 |