Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again
Дата
Msg-id CAL9smLCSS_aPAeYZZP9aR8Rw-F3VdJXEyuPz1EsxPUe_aSgCSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Mar 5, 2018 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Marko Tiikkaja <marko@joh.to> writes:
> So I'm in the same pickle again.  According to pg_stat_user_indexes an
> index is being used all the time.  However, it's only being used by
> mergejoinscansel() to compare these two plans:

If it's not being used otherwise, could you drop it?

Yes.  I want to drop it, as I think it's useless, but it's hard to be 100% sure.
 
> I think it would be really important to have a way to turn off
> get_actual_variable_range() for a specific index during runtime.  Would a C
> level hook be acceptable for this?

You haven't really made a case for why you (or anyone else) should care.
As long as the planner makes the right choice, having investigated a wrong
choice doesn't seem like a bug to me.

Because I'm certain the planner would make the right choice even without the index, and I want it gone.


.m

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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Следующее
От: David Steele
Дата:
Сообщение: Re: Re: WIP Patch: Pgbench Serialization and deadlock errors