Re: less expensive pg_buffercache on big shmem

Hello everyone, patch was rebased.

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

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

 > 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: http://www.postgrespro.com
The Russian Postgres Company