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
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 |