From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_sequence catalog |
Date: | 2016-08-31 18:01:46 |
Message-ID: | 20160831180146.scvrwjmh5dgp7v4z@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
> andres(at)anarazel(dot)de (Andres Freund) writes:
> > On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote:
> >> 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.
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2016-08-31 18:05:41 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Tom Lane | 2016-08-31 17:59:48 | Re: pg_sequence catalog |