Re: Removing special case OID generation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing special case OID generation
Date: 2012-02-13 13:08:08
Message-ID: CA+TgmoaFRf_+fnUnU2kv3kbWjbA1SH2=-CtH1k09wgYpdXWtXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 11, 2012 at 4:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-13 13:14:52 Re: initdb and fsync
Previous Message Kohei KaiGai 2012-02-13 12:51:35 Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)