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

From Amit Kapila
Subject Re: improve transparency of bitmap-only heap scans
Date
Msg-id CAA4eK1J5Vvzpw=vPU3NwmhLb-KqCNMF6YSKsufrBH6ETjvCjDw@mail.gmail.com
Whole thread Raw
In response to Re: improve transparency of bitmap-only heap scans  (James Coleman <jtc331@gmail.com>)
Responses Re: improve transparency of bitmap-only heap scans  (James Coleman <jtc331@gmail.com>)
List pgsql-hackers
On Wed, Mar 25, 2020 at 5:44 PM James Coleman <jtc331@gmail.com> wrote:
>
> 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.
>

Yeah, I also see this information could be useful.  It seems Tom Lane
is not entirely convinced of this.  I am not sure if this is the right
time to seek more opinions as we are already near the end of CF.  So,
we should either decide to move this to the next CF if we think of
getting the opinion of others or simply reject it and see a better way
for EXPLAIN to identify an index-only BMS.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Next
From: Amit Kapila
Date:
Subject: Re: error context for vacuum to include block number