Tomas Vondra tomas.von...@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
Tomas Vondra tomas.von...@2ndquadrant.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,
Yeah. The only use-case that's been suggested is detecting an
unresponsive stats collector, and the main timestamp should be plenty for
that.
Lately, I've spent most of my time doing investigation into increasing
qps. Turned out we've been able to triple our throughput by monitoring
Matt Kelly mkell...@gmail.com writes:
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...)
Committed with a couple of changes:
* I changed the function name from
Matt Kelly mkell...@gmail.com writes:
Yeah. The only use-case that's been suggested is detecting an
unresponsive stats collector, and the main timestamp should be plenty for
that.
The problem with doing highly granular snapshots is that the postgres
counters are monotonically increasing,
On 20.2.2015 02:58, Tom Lane wrote:
Tomas Vondra tomas.von...@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
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 (1) and was from before I read the docs on
properly picking one.
On Fri, Jan 30, 2015 at 12:07:22AM -0500, Tom Lane wrote:
Matt Kelly mkell...@gmail.com writes:
On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... or double. Have you checked that the code behaves properly with
--disable-integer-timestamps?
I presume you meant
On Thu, Jan 29, 2015 at 12:18 AM, Matt Kelly mkell...@gmail.com wrote:
In a previous thread Tom Lane said:
(I'm also wondering if it'd make sense to expose the stats timestamp
as a callable function, so that the case could be dealt with
programmatically as well. But that's future-feature
Robert, I'll add it to the commitfest.
Jim, I'm not sure I understand what you mean? This new function follows
the same conventions as everything else in the file. TimestampTz is just a
typedef for int64. Functions like pg_stat_get_buf_alloc follow the exact
same pattern on the int64 fields of
This is now: https://commitfest.postgresql.org/4/128/
On Thu, Jan 29, 2015 at 7:01 PM, Matt Kelly mkell...@gmail.com wrote:
Robert, I'll add it to the commitfest.
Jim, I'm not sure I understand what you mean? This new function follows
the same conventions as everything else in the file.
Matt Kelly mkell...@gmail.com writes:
Jim, I'm not sure I understand what you mean? This new function follows
the same conventions as everything else in the file. TimestampTz is just a
typedef for int64.
... or double. Have you checked that the code behaves properly with
On 1/28/15 11:18 PM, Matt Kelly wrote:
In a previous thread Tom Lane said:
(I'm also wondering if it'd make sense to expose the stats timestamp
as a callable function, so that the case could be dealt with
programmatically as well. But that's future-feature territory.)
In a previous thread Tom Lane said:
(I'm also wondering if it'd make sense to expose the stats timestamp
as a callable function, so that the case could be dealt with
programmatically as well. But that's future-feature territory.)
14 matches
Mail list logo
