Re: Exposing the stats snapshot timestamp to SQL

Hi there,

On 30.1.2015 06:27, Matt Kelly wrote:
> ​Actually, I just did one more code review of myself, and somehow missed
> that I submitted the version with the wrong oid.  The oid used in the
> first version is wrong (10000) and was from before I read the docs on
> properly picking one.
> 
> Attached is the fixed version. (hopefully with the right mime-type and
> wrong extension.  Alas, gmail doesn't let you set mime-types; time to
> find a new email client...)

I do have a question regarding the patch, although I see the patch is
already marked as 'ready for committer' (sorry, somehow managed to miss
the patch until now).

I see the patch only works with the top-level snapshot timestamp, stored
in globalStats, but since 9.3 (when the stats were split into per-db
files) we track per-database timestamps too.

Shouldn't we make those timestamps accessible too? It's not necessary
for detecting unresponsive statistics collector (if it's stuck it's not
writing anything, so the global timestamp will be old too), but it seems
more appropriate for querying database-level stats to query
database-level timestamp too.

But maybe that's not necessary, because to query database stats you have
to be connected to that particular database and that should write fresh
stats, so the timestamps should not be very different.

regards

-- 
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services