Re: pg_stat_all_tables vs NULLs - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_stat_all_tables vs NULLs
Date
Msg-id 49365508.3050705@hagander.net
Whole thread Raw
In response to Re: pg_stat_all_tables vs NULLs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_stat_all_tables vs NULLs  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: [PATCHES] GIN improvements
Next
From: Magnus Hagander
Date:
Subject: Re: maintenance memory vs autovac