Re: Index Tuning Features

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Index Tuning Features
Дата
Msg-id 29634.1160610313@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Index Tuning Features  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> You would create your proposed index, then run ANALYZE and EXPLAIN to your
> heart's content. When you have it set up just so then you REINDEX your index
> and you're set.

And when you realize you don't want it after all ... you need an exclusive
lock on the table to drop it.  (Yes, you would, see relcache load.)
The advantage of keeping this idea all inside EXPLAIN is that there's
guaranteed to be no interference with anything else.

> We already have these "bogus" indexes incidentally, we just create the index
> with indisvalid=f.

Au contraire, that is something completely different.  indisvalid=f is
really the exact opposite: it's not there to the planner and it is there
to the executor.

As for the statistics business: really, we use the presence of an index
as a hint to gather certain kinds of stats about its underlying table.
If we had (ahem) statistical hints then we could gather appropriate data
with or without a real associated index.  That sort of feature would
have additional uses, ie, being able to estimate selectivities more
accurately for expressions that might not have anything to do with any
of the indexes on a table.
        regards, tom lane


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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Hints WAS: Index Tuning Features
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Repair incorrect check for coercion of unknown literal to