On 2016-09-10 17:23:21 +0530, Amit Kapila wrote: > On Thu, Sep 1, 2016 at 12:00 AM, Andres Freund <and...@anarazel.de> wrote: > > On 2016-08-31 14:23:41 -0400, Tom Lane wrote: > >> Andres Freund <and...@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. > > > > Isn't that *precisely* when it's going to matter? If you have 5 active > > tables & sequences where the latter previously used independent locks, > > and they'd now be contending on a single lock. > > > > I may be missing something here, but why would it contend on a lock, > as per locking scheme proposed by Alvaro, access to sequence object > will need a share lock on buffer page.
To make checkpointing/bgwriter work correctly we need exclusive locks on pages while writing..., or some new lock level preventing the page from being written out, while "shared dirtying" locks are being held. Andres -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers