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

Re: Dynamic Partitioning using Segment Visibility Maps

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dynamic Partitioning using Segment Visibility Maps
Date: 2008-01-04 19:38:24
Message-ID: 1199475504.18598.167.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2008-01-04 at 13:06 -0500, Andrew Sullivan wrote:
> On Fri, Jan 04, 2008 at 01:29:55PM +0100, Markus Schiltknecht wrote:
> > 
> > Agreed. Just a minor note: I find "marked read-only" too strong, as it 
> > implies an impossibility to write. I propose speaking about mostly-read 
> > segments, or optimized for reading or similar.
> 
> I do want some segments to be _marked_ read-only: I want attempted writes to
> them to _fail_.

I think Markus thought that we would mark them read only automatically,
which was not my intention. I believe its possible to have this in a way
that will make you both happy. Some more explanation:

There would be three different states for a segment:
1. read write
2. "optimized for reading", as Markus says it
3. marked read only by explicit command

Transition 1 -> 2 is by autovacuum under the SVM proposal, transition 2
-> 3 is by user command only. So throwing an ERROR is acceptable for
segments in state 3.

I came up with a complex scheme for going from 1 -> 3 previously, but I
don't think its needed any longer (for this, at least). It's trivial to
go from 2 -> 3 using an ALTER TABLE statement, along the lines of ALTER
TABLE .... WHERE .... 

Files that are completely in state 3 can then be archived by a
hierarchical storage manager without problem.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Andrew SullivanDate: 2008-01-04 20:08:07
Subject: Re: SSL over Unix-domain sockets
Previous:From: Bruce MomjianDate: 2008-01-04 19:37:03
Subject: Re: SSL over Unix-domain sockets

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