Re: pg_stat_statements: calls under-estimation propagation
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Daniel Farina <daniel@heroku.com>, Sameer Thakur <samthakur74@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-10-10T18:48:22Z
Lists: pgsql-hackers
On Fri, Oct 11, 2013 at 2:49 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Daniel Farina escribió: >> On Thu, Oct 10, 2013 at 7:40 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > >> > In my test, I found that pg_stat_statements.total_time always indicates a zero. >> > I guess that the patch might handle pg_stat_statements.total_time wrongly. >> > >> > + values[i++] = DatumGetTimestamp( >> > + instr_get_timestamptz(pgss->session_start)); >> > + values[i++] = DatumGetTimestamp( >> > + instr_get_timestamptz(entry->introduced)); >> > >> > These should be executed only when detected_version >= PGSS_TUP_LATEST? >> >> Yes. Oversight. > > Hmm, shouldn't this be conditional on a new PGSS_TUP_V1_2? I was just thinking the same thing. Agreed. Regards, -- Fujii Masao
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve management of "sticky" entries in contrib/pg_stat_statements.
- d5375491f8e3 9.2.0 cited