Craig Ringer <cr...@2ndquadrant.com> writes: > On 31 August 2016 at 22:01, Tom Lane <t...@sss.pgh.pa.us> 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.
> It sounds like you're thinking of something like a normal(ish) heap > tuple where we just overwrite some fields in-place without fiddling > xmin/xmax and making a new row version. Right? Like we currently > overwrite the lone Form_pg_sequence on the 1-page sequence relations. That would be what to do with the nontransactional state. If I recall previous discussions correctly, there's a stumbling block if you want to treat ALTER SEQUENCE changes as transactional --- but maybe that doesn't make sense anyway. If we did want to try that, maybe we need two auxiliary catalogs, one for the transactionally-updatable sequence fields and one for the nontransactional fields. > It feels intuitively pretty gross to effectively dirty-read and write > a few fields of a tuple. But that's what we do all the time with > xmin/xmax etc, it's not really that different. True. I think two rows would work around that, but maybe we don't have to. Another issue is what is the low-level interlock between nextvals in different processes. Right now it's the buffer lock on the sequence's page. With a scheme like this, if we just kept doing that, we'd have a single lock covering probably O(100) different sequences which might lead to contention problems. We could probably improve on that with some thought. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers