Re: pg_sequence catalog

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_sequence catalog
Дата
Msg-id 20160910190940.xr2w7iwgmi5zetrk@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: pg_sequence catalog  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: pg_sequence catalog  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Borodin
Дата:
Сообщение: Re: GiST penalty functions [PoC]
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Tuplesort merge pre-reading