Re: improve transparency of bitmap-only heap scans

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: error context for vacuum to include block number
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: error context for vacuum to include block number