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
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 |