Thread: SLRU_BLCKSZ

SLRU_BLCKSZ

From
Simon Riggs
Date:
Code changes to separate out the symbol for SLRU_BLCKSZ from standard
BLCKSZ. Same reasons as for doing this for XLOG_BLCKSZ.

If no objections, I'll add this to pg_* binaries and the control file
also.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com

Attachment

Re: SLRU_BLCKSZ

From
Tom Lane
Date:
Simon Riggs <simon@2ndquadrant.com> writes:
> Code changes to separate out the symbol for SLRU_BLCKSZ from standard
> BLCKSZ. Same reasons as for doing this for XLOG_BLCKSZ.

Have you done any benchmarking that shows this is a good idea?

My own thoughts on the subject have been along the line that pages for
different slru logs possibly need to be different sizes, so that eg
we could have more than 2K subtransactions per page.  I'm not sure this
is worthwhile (is there any place in slru.c that depends on a fixed page
size for efficiency?) but it needs to be considered before we make
purely cosmetic changes in the area.

            regards, tom lane

Re: SLRU_BLCKSZ

From
Simon Riggs
Date:
On Wed, 2006-05-17 at 10:05 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Code changes to separate out the symbol for SLRU_BLCKSZ from standard
> > BLCKSZ. Same reasons as for doing this for XLOG_BLCKSZ.
>
> Have you done any benchmarking that shows this is a good idea?

Some, with more coming.

> My own thoughts on the subject have been along the line that pages for
> different slru logs possibly need to be different sizes, so that eg
> we could have more than 2K subtransactions per page.

That's what I thought at first.

> I'm not sure this
> is worthwhile (is there any place in slru.c that depends on a fixed page
> size for efficiency?) but it needs to be considered before we make
> purely cosmetic changes in the area.

You raised the possible impact of clog extension doing WAL logging, so
doing that less often seems sensible.

Increasing all of them could have benefit, for different reasons - so
having different block sizes for each seems like overkill - and harder
to record in the control file and utilities.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com