Re: Reducing planning time on tables with many indexes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing planning time on tables with many indexes
Дата
Msg-id 3009057.1658942102@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reducing planning time on tables with many indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Reducing planning time on tables with many indexes  (David Geier <geidav.pg@gmail.com>)
Список pgsql-hackers
I wrote:
> Unfortunately, as things stand today, the planner needs more than the
> right to look at the indexes' schemas, because it makes physical accesses
> to btree indexes to find out their tree height (and I think there are some
> comparable behaviors in other AMs).  I've never particularly cared for
> that implementation, and would be glad to rip out that behavior if we can
> find another way.  Maybe we could persuade VACUUM or ANALYZE to store that
> info in the index's pg_index row, or some such, and then the planner
> could use it with no lock?

A first step here could just be to postpone fetching _bt_getrootheight()
until we actually need it during cost estimation.  That would avoid the
need to do it at all for indexes that indxpath.c discards as irrelevant,
which is a decision made on considerably more information than the
proposed patch uses.

Having done that, you could look into revising plancat.c to fill the
IndexOptInfo structs from catcache entries instead of opening the
index per se.  (You'd have to also make sure that the appropriate
index locks are acquired eventually, for indexes the query does use
at runtime.  I think that's the case, but I'm not sure if anything
downstream has been optimized on the assumption the planner did it.)

This'd probably get us a large part of the way there.  Further
optimization of acquisition of tree height etc could be an
optional follow-up.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reducing planning time on tables with many indexes
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: Remove the restriction that the relmap must be 512 bytes.