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 по дате отправления: