Re: distinguish index cost component from table component

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: distinguish index cost component from table component
Дата
Msg-id 20200103160315.GL12066@telsasoft.com
обсуждение исходный текст
Ответ на Re: distinguish index cost component from table component  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
On Fri, Jan 03, 2020 at 09:33:35AM -0500, Jeff Janes wrote:
> Of course this doesn't really answer your question, as the
> separately-reported costs of a bitmap heap and bitmap index scan are
> unlikely to match what the costs would be of a regular index scan, if they
> were reported separately.

I think the cost of index component of bitmap scan would be exactly the same
as the cost of the original indexscan.

>> Or maybe explain should report it.
> 
> I wouldn't be optimistic about getting such a backwards-incompatible change
> accepted (plus it would surely add some small accounting overhead, which
> again would probably not be acceptable). But if you do enough tuning work,
> perhaps it would be worth carrying an out-of-tree patch to implement that.
> I wouldn't be so interested in writing such a patch, but would be
> interested in using one were it available somewhere.

I did the attached in the simplest possible way.  If it's somehow possible get
the path's index_total_cost from the plan, then there'd be no additional
overhead.

Justin

Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: distinguish index cost component from table component
Следующее
От: Marco Colli
Дата:
Сообщение: Bad query plan when you add many OR conditions