Re: less expensive pg_buffercache on big shmem

From: Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: less expensive pg_buffercache on big shmem
Date: 2016-09-28 23:45:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello everyone, patch was rebased.

Thank you Tomas for your reviewing this patch and for your valuable

From the very beginning we had the misunderstanding with the naming of

> It'd be really useful if you could provide actual numbers, explain what
> metrics you compare and how. I'm sure it makes sense to you but it's
> utterly confusing for everyone else, and it also makes it impossible to
> reproduce the benchmark.

I test it as I wrote earlier, I run it a several times collecting TPS in
each series, and calculate average value.

> Secondly, I see this bit added to the loop over buffers:
> if (bufHdr->tag.forkNum == -1)
> {
> fctx->record[i].blocknum = InvalidBlockNumber;
> continue;
> }
> and I have no idea why this is needed (when it was not needed before).

This helps to skip not used bufferpages. It is valuable on big and not
warmup shared memory.

On 09/02/2016 12:01 PM, Robert Haas wrote:
> I think we certainly want to lock the buffer header, because otherwise
> we might get a torn read of the buffer tag, which doesn't seem good.
> But it's not obvious to me that there's any point in taking the lock
> on the buffer mapping partition; I'm thinking that doesn't really do
> anything unless we lock them all, and we all seem to agree that's
> going too far.

Replace consistent method with semiconsistent (that lock buffer headers
without partition lock). Made some additional fixes thanks to reviewers.

Ivan Kartyshov
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
pg_buffercache_v1_3.patch text/x-patch 4.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-09-28 23:52:18 Re: Transaction user id through logical decoding
Previous Message Jeff Janes 2016-09-28 23:01:56 Re: Better tracking of free space during SP-GiST index build