From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Markus Schiltknecht <markus(at)bluegap(dot)ch>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
Subject: | Re: Dynamic Partitioning using Segment Visibility Maps |
Date: | 2008-01-05 03:31:14 |
Message-ID: | 200801042231.15295.xzilla@users.sourceforge.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday 04 January 2008 17:01, Simon Riggs wrote:
> On Fri, 2008-01-04 at 22:26 +0100, Markus Schiltknecht wrote:
> > I'm still puzzled about how a DBA is expected to figure out which
> > segments to mark. Simon, are you assuming we are going to pass on
> > segment numbers to the DBA one day?
>
> No Way!
>
> That would stop Richard's idea to make the segment stride configurable,
> apart from being a generally ugly thing.
>
> > If not, a more user friendly command like "MARK READ ONLY WHERE date <=
> > 2006" would have to move tuples around between segments, so as to be
> > able to satisfy the split point exactly, right?
>
> Yes, just a simple WHERE clause that we can translate into segments
> under the covers. It would be an alter table, so we get an exclusive
> lock.
>
> ALTER TABLE foo SET READ ONLY WHERE ....
>
> possibly with a few restrictions on the WHERE clause. Anyway this is
> just futures and dreams, so far, so lets just say something like that is
> possible in the future and work out more when we pass the first few
> hurdles.
Not to be negative, but istm how this feature would be managed is as important
as the bits under the hood. Or at least we have to believe there will be
some practical way to manage this, which as of yet I am skeptical.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Warren Turkal | 2008-01-05 07:23:56 | Re: timestamp typedefs |
Previous Message | Tom Lane | 2008-01-05 03:09:30 | Re: OUTER JOIN performance regression remains in 8.3beta4 |