Re: pg_sequence catalog - Mailing list pgsql-hackers

From andres@anarazel.de (Andres Freund)
Subject Re: pg_sequence catalog
Date
Msg-id 20160831172803.fg2fjtizthvvglxl@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_sequence catalog  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_sequence catalog  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> > 
> > On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> > > Improving on the space wastage is exactly the point IMO.  If it's still
> > > going to be 8k per sequence on disk (*and* in shared buffers, remember),
> > > I'm not sure it's worth all the work to change things at all.
> > 
> > A separate file is a heck lot more heavyweight than another 8 kb in an
> > existing file.
> 
> Yes, sure, we're still improving even if we stick to one-seq-per-bufpage,
> but while we're at it, we could as well find a way to make it as best as
> we can.  And allowing multiple seqs per page seems a much better
> situation, so let's try to get there.

It's not really that simple. Having independent sequence rows closer
together will have its own performance cost. Suddenly independent
sequences will compete for the same page level lock, NUMA systems will
have to transfer the page/cacheline around even if it's independent
sequences being accessed in different backends, we'll have to take care
about cacheline padding...



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_sequence catalog
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Use static inline functions for float <-> Datum conversions.