Matt Kelly 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, but only when
>
> 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
expe
Tomas Vondra 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_re
Matt Kelly 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 pg_stat_snapshot_timestamp to
p
On 20.2.2015 02:58, Tom Lane wrote:
> Tomas Vondra 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 ac
Tomas Vondra 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 detec
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.
>
> At
On Fri, Jan 30, 2015 at 12:07:22AM -0500, Tom Lane wrote:
> Matt Kelly writes:
> > On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
> >> ... or double. Have you checked that the code behaves properly with
> >> --disable-integer-timestamps?
>
> > I presume you meant --disable-integer-datetimes.
​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.
Attached is the fixed version. (hopefully with the right mime-t
Matt Kelly writes:
> On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
>> ... or double. Have you checked that the code behaves properly with
>> --disable-integer-timestamps?
> I presume you meant --disable-integer-datetimes. I just ran that test case
> now, all set.
Right, my own sloppiness t
On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
> Matt Kelly 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 th
Matt Kelly 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
--disable-integer-timestamps?
This is now: https://commitfest.postgresql.org/4/128/
On Thu, Jan 29, 2015 at 7:01 PM, Matt Kelly 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. TimestampTz is ju
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
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.)
(http://www.p
On Thu, Jan 29, 2015 at 12:18 AM, 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.)
(http://www.postgresql.org/message-id/27251.1421684...@sss.pg
17 matches
Mail list logo
