Re: improve transparency of bitmap-only heap scans

From: James Coleman <jtc331(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, David Steele <david(at)pgmasters(dot)net>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, Emre Hasegeli <emre(at)hasegeli(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improve transparency of bitmap-only heap scans
Date: 2020-03-25 12:14:41
Message-ID: CAAaqYe8hm1CxfSRP5zPyArxfvByFZ+BjgDOWxyMwSY1=JEuMVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Mar 25, 2020 at 12:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-03-25 12:27:44 Re: error context for vacuum to include block number
Previous Message Justin Pryzby 2020-03-25 11:39:17 Re: error context for vacuum to include block number