Re: improve transparency of bitmap-only heap scans - Mailing list pgsql-hackers

From James Coleman
Subject Re: improve transparency of bitmap-only heap scans
Date
Msg-id CAAaqYe8hm1CxfSRP5zPyArxfvByFZ+BjgDOWxyMwSY1=JEuMVA@mail.gmail.com
Whole thread Raw
In response to Re: improve transparency of bitmap-only heap scans  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: improve transparency of bitmap-only heap scans  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Mar 25, 2020 at 12:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > I took a quick look through this patch.  While I see nothing to complain
> > about implementation-wise, I'm a bit befuddled as to why we need this
> > reporting when there is no comparable data provided for regular index-only
> > scans.  Over there, you just get "Heap Fetches: n", and the existing
> > counts for bitmap scans seem to cover the same territory.
> >
>
> Isn't deducing similar information ("Skipped Heap Fetches: n") there
> is a bit easier than it is here?

While I'm not the patch author so can't speak to the original thought
process, I do think it makes sense to show it. I could imagine a world
in which index only scans were printed in explain as purely an
optimization to index scans that shows exactly this (how many pages we
were able to skip fetching). That approach actually can make things
more helpful than the approach current in explain for index only
scans, since the optimization isn't all or nothing (i.e., it can still
fetch heap pages), so it's interesting to see exactly how much it
gained you.

James



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: error context for vacuum to include block number
Next
From: Masahiko Sawada
Date:
Subject: Re: error context for vacuum to include block number