Re: alternative back-end block formats

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: alternative back-end block formats
Дата
Msg-id 52E4E7D3.1040505@2ndquadrant.com
обсуждение исходный текст
Ответ на alternative back-end block formats  (Christian Convey <christian.convey@gmail.com>)
Ответы Re: alternative back-end block formats  (Christian Convey <christian.convey@gmail.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Visual Studio 2013 build
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Standalone synchronous master