num_sa_scans in genericcostestimate

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема num_sa_scans in genericcostestimate
Дата
Msg-id CAMkU=1zaB2JV9O=XxGn7AqUEw_nB7zo-ExTiT40OnkJZ596qbg@mail.gmail.com
обсуждение исходный текст
Ответы Re: num_sa_scans in genericcostestimate  (Jeff Janes <jeff.janes@gmail.com>)
Re: num_sa_scans in genericcostestimate  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
When costing a btree index scan, num_sa_scans gets computed twice, once in btcostestmeate and once in genericcostestimate.  But the computations are different.  It looks like the generic one includes all =ANY in any column in the index, while the bt one includes only =ANY which or on columns for which all the preceding index columns are tested for equality.

It looks like the generic one was there first then the bt-specific one was added later to improve planning of btree indexes.  But then shouldn't the value be passed down to generic, rather than recomputed (differently)?  I've attached a patch to do that.  Generic still computes the value itself for other-than-btree indexes.

Or, is there a reason we want a different value to be used in genericcostestimate?

The context for this is that I was looking at cases where btree indexes were not using all the columns they could, but rather shoving some of the conditions down into a Filter unnecessarily/unhelpfully.  This change doesn't fix that, but it does seem to be moving in the right direction.

This does cause a regression test failure due to an (apparently?) uninteresting plan change.

Cheers,

Jeff
Вложения

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

Предыдущее
От: Nikita Malakhov
Дата:
Сообщение: Re: Proposal: CREATE/ALTER DOMAIN ... STORAGE/COMPRESSION = ...
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Perform streaming logical transactions by background workers and parallel apply