Re: Dynamic Partitioning using Segment Visibility Maps

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dynamic Partitioning using Segment Visibility Maps
Date: 2008-01-03 09:44:25
Message-ID: 1199353465.7260.173.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2008-01-03 at 00:41 +0000, Sam Mason wrote:
> On Wed, Jan 02, 2008 at 05:56:14PM +0000, Simon Riggs wrote:
> > Like it?
>
> Sounds good. I've only given it a quick scan though. Would read-only
> segments retain the same disk-level format as is currently?

Yes, no changes at all to the table. So your app would just work,
without any DDL changes. Existing partitioning apps would not change.

> It seems
> possible to remove the MVCC fields and hence get more tuples per page---
> whether this would actually be a net performance gain/loss seems like
> a difficult question question to answer, it would definitly be a
> complexity increase though.

I've been looking at general compression at table and segment level, but
thats further down the track. Removing the MVCC fields is too much work,
I think.

> Reading this reminds me of the design of the store for a persistent
> operating system called EROS. It has a very good paper[1] describing
> the design (implementation and careful benchmarking thereof) that I
> think could be a useful read.

Thanks, will do.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2008-01-03 10:23:31 Re: Table rewrites vs. pending AFTER triggers
Previous Message David Fetter 2008-01-03 08:11:00 Re: Table rewrites vs. pending AFTER triggers