Re: pg_stat_statements: calls under-estimation propagation
Daniel Farina <daniel@heroku.com>
From: Daniel Farina <daniel@heroku.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
Sameer Thakur <samthakur74@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-10-10T20:54:50Z
Lists: pgsql-hackers
On Thu, Oct 10, 2013 at 1:30 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> > Just noticed that you changed the timer to struct Instrumentation. Not >> > really sure about that change. Since you seem to be using only the >> > start time and counter, wouldn't it be better to store only those? >> > Particularly unsure about passing INSTRUMENT_ALL to InstrAlloc(). >> >> Yeah, I was unsure about that too. >> >> The motivation was that I need one more piece of information in >> pgss_store (the absolute start time). I was going to widen the >> argument list, but it was looking pretty long, so instead I was >> thinking it'd be more concise to push the entire, typically extant >> Instrumentation struct pointer down. > > Would it work to define your own struct to pass around? Absolutely, I was just hoping to spare the code another abstraction if another was a precise superset. Looks like that isn't going to happen, though, so a pgss-oriented struct is likely what will have to be.
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