Re: pg_stat_statements: calls under-estimation propagation
От | Daniel Farina |
---|---|
Тема | Re: pg_stat_statements: calls under-estimation propagation |
Дата | |
Msg-id | CAAZKuFatZCguMx2SSkzyzUrcSaGVvtBHWG1zwD=1jhE3Car9Cw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_statements: calls under-estimation propagation (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pg_stat_statements: calls under-estimation propagation
|
Список | 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 по дате отправления: