Re: pg_stat_all_tables vs NULLs

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pg_stat_all_tables vs NULLs
Дата
Msg-id 49365508.3050705@hagander.net
обсуждение исходный текст
Ответ на Re: pg_stat_all_tables vs NULLs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_stat_all_tables vs NULLs  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> I've noticed that pg_stat_all_tables returns NULL for idx_scan and
>> idx_tup_fetch if there are no indexes present on a table.
> 
>> Is this actually intended, or is that something that should be fixed?
> 
> Hmm.  I suspect it's an implementation artifact rather than something
> that was consciously chosen, but on reflection it doesn't seem like a
> bad thing.  If we just COALESCE'd it to zero (which I assume is what
> you have in mind) then there would be no distinction in the view
> between "you have no indexes" and "there are indexes but they aren't
> being used".

But does it make sense to look for that information in pg_stat_*_tables,
really? If you want to know if an index exists for a table, you'd
normally go look in the system tables, not the statistics views, I think.


> I'd vote to leave it alone, I think.

I can go for that as well though. I'd say "Let's document it instead
then", but it seems the stats views documentation is very short on what
actually goes in the fields. But I guess we could just add a "(NULL if
no indexes are present)" to that?

In the long term it might be worthwhile to rewrite that section of the
docs to focus more on the stats views (giving each it's own section with
more information bout it than just a list of fields) and less on the
underlying implementation functions. But that's a different day ;-)


//Magnus


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [PATCHES] GIN improvements
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: maintenance memory vs autovac