Skip site navigation (1) Skip section navigation (2)

Re: Dynamic Partitioning using Segment Visibility Maps

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: (view raw, whole thread or download thread mbox)
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.
> 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

In response to


pgsql-hackers by date

Next:From: Warren TurkalDate: 2008-01-05 07:23:56
Subject: Re: timestamp typedefs
Previous:From: Tom LaneDate: 2008-01-05 03:09:30
Subject: Re: OUTER JOIN performance regression remains in 8.3beta4

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group