Re: Stats collector's idx_blks_hit value is highly misleading in practice

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stats collector's idx_blks_hit value is highly misleading in practice
Date: 2022-02-04 00:08:22
Message-ID: CAFBsxsH+FPGwE4bUCFi21mKXpTA0J4NS1wnyOYYX73gdHZZBHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 30, 2020 at 9:46 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:
>
> On Fri, Oct 16, 2020 at 03:35:51PM -0700, Peter Geoghegan wrote:

> >I suppose that a change like this could end up affecting other things,
> >such as EXPLAIN ANALYZE statistics. OTOH we only break out index pages
> >separately for bitmap scans at the moment, so maybe it could be fairly
> >well targeted. And, maybe this is unappealing given the current
> >statistics collector limitations. I'm not volunteering to work on it
> >right now, but it would be nice to fix this. Please don't wait for me
> >to do it.
> >
>
> It seems to me this should not be a particularly difficult patch in
> principle, so suitable for new contributors. The main challenge would be
> passing information about what page we're dealing with (internal/leaf)
> to the place actually calling pgstat_count_buffer_(read|hit). That
> happens in ReadBufferExtended, which just has no idea what page it's
> dealing with. Not sure how to do that cleanly ...

Is this a TODO candidate? What would be a succinct title for it?

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-02-04 00:14:53 Re: Fix CheckIndexCompatible comment
Previous Message David Rowley 2022-02-04 00:07:42 Re: Fix BUG #17335: Duplicate result rows in Gather node