Re: pg_sequence catalog - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_sequence catalog
Date
Msg-id 20160910190940.xr2w7iwgmi5zetrk@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_sequence catalog  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_sequence catalog  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2016-09-10 17:23:21 +0530, Amit Kapila wrote:
> On Thu, Sep 1, 2016 at 12:00 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-08-31 14:23:41 -0400, Tom Lane wrote:
> >> 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.
> >
> > 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



pgsql-hackers by date:

Previous
From: Andrew Borodin
Date:
Subject: Re: GiST penalty functions [PoC]
Next
From: Peter Geoghegan
Date:
Subject: Re: Tuplesort merge pre-reading