Re: SLRU statistics

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SLRU statistics
Date: 2020-05-14 02:18:53
Message-ID: bfe31847-78ce-7158-d917-dbdb9f49749b@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/05/14 2:44, Tom Lane wrote:
> I wrote:
>>>> (IIRC only the Async module is doing that.)
>
>> Hm, maybe we can fix that.
>
> Yeah, it's quite easy to make async.c postpone its first write to the
> async SLRU. This seems like a win all around, because many installations
> don't use NOTIFY and so will never need to do that work at all. In
> installations that do use notify, this costs an extra instruction or
> two per NOTIFY, but that's down in the noise.

Looks good to me. Thanks for the patch!

> I got through check-world with the assertion shown that we are not
> counting any SLRU operations in the postmaster. Don't know if we
> want to commit that or not --- any thoughts?

+1 to add this assertion because basically it's not good thing
to access to SLRU at postmaster and we may want to fix that if found.
At least if we get rid of the SLRUStats initialization code,
IMO it's better to add this assertion and ensure that postmaster
doesn't update the SLRU stats counters.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Suraj Kharage 2020-05-14 02:20:22 Re: refactoring basebackup.c
Previous Message godjan • 2020-05-14 02:18:33 Re: Strange decreasing value of pg_last_wal_receive_lsn()