Re: alternative back-end block formats

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Christian Convey <christian(dot)convey(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: alternative back-end block formats
Date: 2014-01-26 10:47:47
Message-ID: 52E4E7D3.1040505@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/21/2014 07:43 PM, Christian Convey wrote:
> Hi all,
>
> I'm playing around with Postgres, and I thought it might be fun to
> experiment with alternative formats for relation blocks, to see if I can
> get smaller files and/or faster server performance.

It's not clear how you'd do this without massively rewriting the guts of Pg.

Per the docs on internal structure, Pg has a block header, then tuples
within the blocks, each with a tuple header and list of Datum values for
the tuple. Each Datum has a generic Datum header (handling varlena vs
fixed length values etc) then a type-specific on-disk representation
controlled by the type output function for that type.

At least, that's my understanding - I haven't had cause to delve into
the on-disk format yet.

What concrete problem do you mean to tackle? What idea do you want to
explore or implement?

> Does anyone know if this has been done before with Postgres? I would
> have assumed yes, but I'm not finding anything in Google about people
> having done this.

AFAIK (and I don't know much in this area) the storage manager isn't
very pluggable compared to the rest of Pg.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2014-01-26 12:42:28 Re: Standalone synchronous master
Previous Message Magnus Hagander 2014-01-26 10:44:12 Re: Visual Studio 2013 build