Re: Removing special case OID generation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Removing special case OID generation
Дата
Msg-id CA+TgmoaFRf_+fnUnU2kv3kbWjbA1SH2=-CtH1k09wgYpdXWtXw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing special case OID generation  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Removing special case OID generation  (Marti Raudsepp <marti@juffo.org>)
Re: Removing special case OID generation  (Andres Freund <andres@anarazel.de>)
Re: Removing special case OID generation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Yeh, I was thinking we would do well to implement cached sequences for
> say first 1000 sequences.

Another option might be to store all the sequences for a particular
database in a single underlying data file.  The current implementation
uses a whole page for a single tuple that is presumably much smaller
than that.  So when you create a sequence "foo", it's really creating
a row in some new system catalog pg_sequences, or something like that.

> Idea would be to make Sequences as fast as OIDs and get rid of the
> weird OID code.

Honestly, I think the biggest hassle of the OID code is not so much
the way they're generated as the way they're stored within heap
tuples.  I've wondered whether we should go through the system
catalogs and replace all of the hidden OID columns with a normal
column called "oid" of type OID, always placing it at attnum = 1 since
we have a lot of code that assumes the OID column always has the same
attnum.  That would be a fairly large notational change, but maybe it
wouldn't break anything /too/ badly...

Anyway, if we could get away with that, we could eventually (after N
releases) drop the special case support for system OID columns, which
would be a nice simplification.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: initdb and fsync