Re: Exposing the stats snapshot timestamp to SQL

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> Well, the patch also does this:

> *** 28,34 **** SELECT pg_sleep_for('2 seconds');
> CREATE TEMP TABLE prevstats AS
> SELECT t.seq_scan, t.seq_tup_read, t.idx_scan, t.idx_tup_fetch,
> (b.heap_blks_read + b.heap_blks_hit) AS heap_blks,
> ! (b.idx_blks_read + b.idx_blks_hit) AS idx_blks
> FROM pg_catalog.pg_stat_user_tables AS t,
> pg_catalog.pg_statio_user_tables AS b
> WHERE t.relname='tenk2' AND b.relname='tenk2';
> --- 28,35 ----
> CREATE TEMP TABLE prevstats AS
> SELECT t.seq_scan, t.seq_tup_read, t.idx_scan, t.idx_tup_fetch,
> (b.heap_blks_read + b.heap_blks_hit) AS heap_blks,
> ! (b.idx_blks_read + b.idx_blks_hit) AS idx_blks,
> ! pg_stat_snapshot_timestamp() as snap_ts
> FROM pg_catalog.pg_stat_user_tables AS t,
> pg_catalog.pg_statio_user_tables AS b
> WHERE t.relname='tenk2' AND b.relname='tenk2';
> ***************

That's merely a regression test to verify that the value appears to
advance from time to time ... I don't think it has any larger meaning.
(It will be interesting to see what this new test query reports in the
transient buildfarm failures we still occasionally see in the stats
test.)

regards, tom lane