|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>|
|Subject:||Re: less expensive pg_buffercache on big shmem|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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;
> 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.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|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|