| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Exposing the stats snapshot timestamp to SQL |
| Date: | 2015-02-20 01:58:11 |
| Message-ID: | 21440.1424397491@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2015-02-20 02:08:54 | Re: Exposing the stats snapshot timestamp to SQL |
| Previous Message | Tom Lane | 2015-02-20 01:26:45 | Idea: closing the loop for "pg_ctl reload" |