Re: pg_stat_statements: calls under-estimation propagation - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: pg_stat_statements: calls under-estimation propagation
Date
Msg-id CAAZKuFatZCguMx2SSkzyzUrcSaGVvtBHWG1zwD=1jhE3Car9Cw@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements: calls under-estimation propagation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_stat_statements: calls under-estimation propagation  (Sameer Thakur <samthakur74@gmail.com>)
List 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.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: dynamic shared memory: wherein I am punished for good intentions
Next
From: Josh Berkus
Date:
Subject: Re: dynamic shared memory: wherein I am punished for good intentions