Re: Exposing the stats snapshot timestamp to SQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Exposing the stats snapshot timestamp to SQL
Date
Msg-id 21440.1424397491@sss.pgh.pa.us
Whole thread Raw
In response to Re: Exposing the stats snapshot timestamp to SQL  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Exposing the stats snapshot timestamp to SQL  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> 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.

I'm inclined to say not; I think that's exposing an implementation detail
that we might regret exposing, later.  (IOW, it's not hard to think of
rearrangements that might mean there wasn't a per-database stamp anymore.)

> 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.

Yeah.  The only use-case that's been suggested is detecting an
unresponsive stats collector, and the main timestamp should be plenty for
that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Allow "snapshot too old" error, to prevent bloat
Next
From: Tomas Vondra
Date:
Subject: Re: Exposing the stats snapshot timestamp to SQL