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 CAA4eK1K5bE_ujgyRN-H-D-ebxLD-W+pffSyGZUpU0Cz53eDFDg@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Mar 28, 2020 at 8:02 PM James Coleman <jtc331@gmail.com> wrote:
>
> On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > 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.
>
> I'm curious if Tom's objection is mostly on the grounds that we should
> be consistent in what's displayed, or that he thinks the information
> is likely to be useless.
>

Yeah, it would be good if he clarifies his position.

> If consistency is the goal you might e.g., do something that just
> changes the node type output, but in favor of changing that, it seems
> to me that showing "how well did the optimization" is actually more
> valuable than "did we do the optimization at all". Additionally I
> think showing it as an optimization of an existing node is actually
> likely less confusing anyway.
>
> One other thing: my understanding is that this actually matches the
> underlying code split too. For the index only scan case, we actually
> have a separate node (it's not just an optimization of the standard
> index scan). There are discussions about whether that's a good thing,
> but it's what we have. In contrast, the bitmap scan actually has it as
> a pure optimization of the existing bitmap heap scan node.
>

I personally see those as valid points.  Does anybody else want to
weigh in here, so that we can reach to some conclusion and move ahead
with this CF entry?

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Missing errcode() in ereport
Next
From: Tom Lane
Date:
Subject: Re: snapper vs. HEAD