Re: pg_stat_statements: calls under-estimation propagation

On Thu, Oct 3, 2013 at 5:11 PM, Sameer Thakur <samthakur74(at)gmail(dot)com> wrote:
> On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur <samthakur74(at)gmail(dot)com> wrote:
>>>
>>> Looks pretty good. Do you want to package up the patch with your
>>> change and do the honors and re-submit it? Thanks for helping out so
>>> much!
>> Sure, will do. Need to add a bit of documentation explaining
>> statistics session as well.
>> I did some more basic testing around pg_stat_statements.max, now that
>> we have clarity from Peter about its value being legitimate below 100.
>> Seems to work fine, with pg_stat_statements =4 the max unique queries
>> in the view are 4. On the 5th query the view holds just the latest
>> unique query discarding the previous 4. Fujii had reported a
>> segmentation fault in this scenario.
>> Thank you for the patch
>
> Please find the patch attached

Thanks for the patch! Here are the review comments:

+ OUT session_start timestamptz,
+ OUT introduced timestamptz,

The patch exposes these columns in pg_stat_statements view.
These should be documented.

I don't think that session_start should be exposed in every
rows in pg_stat_statements because it's updated only when
all statistics are reset, i.e., session_start of all entries
in pg_stat_statements indicate the same.

+ OUT query_id int8,

query_id or queryid? I like the latter. Also the document
uses the latter.

Regards,

--
Fujii Masao