Re: BufferAlloc: don't take two simultaneous locks

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: BufferAlloc: don't take two simultaneous locks
Date: 2022-01-22 07:56:14
Message-ID: 294BEBA2-92D9-4932-A449-AE471EF9FF97@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 21 дек. 2021 г., в 10:23, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> написал(а):
>
> <v1-0001-bufmgr-do-not-acquire-two-partition-lo.patch>

Hi Yura!

I've took a look into the patch. The idea seems reasonable to me: clearing\evicting old buffer and placing new one seem to be different units of work, there is no need to couple both partition locks together. And the claimed performance impact is fascinating! Though I didn't verify it yet.

On a first glance API change in BufTable does not seem obvious to me. Is void *oldelem actually BufferTag * or maybe BufferLookupEnt *? What if we would like to use or manipulate with oldelem in future?

And the name BufTableFreeDeleted() confuses me a bit. You know, in C we usually free(), but in C++ we delete [], and here we do both... Just to be sure.

Thanks!

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-01-22 09:10:18 Re: Proposal: allow database-specific role memberships
Previous Message Shruthi Gowda 2022-01-22 07:20:30 Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)