Re: pg_sequence catalog

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_sequence catalog
Date: 2016-08-31 14:40:25
Message-ID: 002b2371-c4a3-7f31-7f28-bbe5ca07bc27@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31/08/16 16:10, Tom Lane wrote:
> I wrote:
>> Personally, my big beef with the current approach to sequences is that
>> we eat a whole relation (including a whole relfilenode) per sequence.
>> I wish that we could reduce a sequence to just a single row in a
>> catalog, including the nontransactional state. Not sure how feasible
>> that is either, but accomplishing it would move the benefits of making
>> a change out of the "debatable whether it's worth it" category, IMO.
>
> BTW, another thing to keep in mind here is the ideas that have been
> kicked around in the past about alternative sequence implementations
> managed through a "sequence AM API". I dunno whether now is the time
> to start creating that API abstraction, but let's at least consider
> it if we're whacking the catalog representation around.
>

FWIW if I was going to continue with the sequence AM API, the next patch
would have included split of sequence metadata and sequence state into
separate catalogs, so from that point this actually seems like an
improvement (I didn't look at the code though).

As a side note, I don't plan to resurrect the seqam patch at least until
we have reasonable built-in logical replication functionality.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-08-31 14:41:48 Re: some requests on auditing
Previous Message Craig Ringer 2016-08-31 14:35:03 Re: pg_sequence catalog