Re: improve transparency of bitmap-only heap scans

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: improve transparency of bitmap-only heap scans
Дата
Msg-id CAA4eK1J5Vvzpw=vPU3NwmhLb-KqCNMF6YSKsufrBH6ETjvCjDw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: improve transparency of bitmap-only heap scans  (James Coleman <jtc331@gmail.com>)
Ответы Re: improve transparency of bitmap-only heap scans  (James Coleman <jtc331@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: error context for vacuum to include block number