Re: pg_sequence catalog - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_sequence catalog
Date
Msg-id 8012.1472667821@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_sequence catalog  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_sequence catalog  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
>> You are ignoring the performance costs associated with eating 100x more
>> shared buffer space than necessary.

> I doubt that's measurable in any real-world scenario. You seldomly have
> hundreds of thousands of sequences that you all select from at a high
> rate.

If there are only a few sequences in the database, cross-sequence
contention is not going to be a big issue anyway.  I think most of
the point of making this change at all is to make things work better
when you do have a boatload of sequences.

Also, we could probably afford to add enough dummy padding to the sequence
tuples so that they're each exactly 64 bytes, thereby having only one
or two active counters per cache line.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Next
From: Andres Freund
Date:
Subject: Re: pg_sequence catalog