Re: Inefficiency in SLRU stats collection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: tomas(dot)vondra(at)2ndquadrant(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Inefficiency in SLRU stats collection
Date: 2020-05-13 14:42:43
Message-ID: 389.1589380963@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> AFAICS it is right and the change suggested looks reasonable to me.
> One arguable point might be whether it is right that SlruData holds
> pgstats internal index from the standpoint of modularity. (It is one
> of the reasons I didn't propose a patch for that..)

Yeah, this is a fair point. On the other hand, the existing code has
pgstat.c digging into the SLRU control structure, which is as bad or
worse a modularity violation. Perhaps we could ditch that by having
slru.c obtain and store the integer index which it then passes to
the pgstat.c counter routines, rather than passing a SlruCtl pointer.

I'll have to look at whether 28cac71bd exposed a data structure that
was formerly private, but if it did I'd be VERY strongly inclined
to revert that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-05-13 14:46:30 Re: SLRU statistics
Previous Message Антон Пацев 2020-05-13 14:28:52 Ideas about moving live rows to the top of the table