Re: pg_stat_statements: calls under-estimation propagation

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: samthakur74 <samthakur74(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements: calls under-estimation propagation
Date: 2013-09-19 06:01:34
Message-ID: CAHGQGwEhWAP9nSXPSdeJDpxjmq5YD0Y7VFmyngC-PnHKSSjUYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 19, 2013 at 2:25 PM, samthakur74 <samthakur74(at)gmail(dot)com> wrote:
>>I got the segmentation fault when I tested the case where the
>> least-executed
>>query statistics is discarded, i.e., when I executed different queries more
>> than
>>pg_stat_statements.max times. I guess that the patch might have a bug.
> Thanks, will try to fix it.
>
>> >pg_stat_statements--1.1.sql should be removed.
>> Yes will do that
>
>
>>
>> >+ <entry><structfield>queryid</structfield></entry>
>> >+ <entry><type>bigint</type></entry>
>> >+ <entry></entry>
>> >+ <entry>Unique value of each representative statement for the
>> >current statistics session.
>> >+ This value will change for each new statistics session.</entry>
>>
>> >What does "statistics session" mean?
>> The time period when statistics are gathered by statistics collector
>> without being reset. So the statistics session continues across normal
>> shutdowns, but in case of abnormal situations like crashes, format upgrades
>> or statistics being reset for any other reason, a new time period of
>> statistics collection starts i.e. a new statistics session. The queryid
>> value generation is linked to statistics session so emphasize the fact that
>> in case of crashes,format upgrades or any situation of statistics reset, the
>> queryid for the same queries will also change.

I'm afraid that this behavior narrows down the use case of queryid very much.
For example, since the queryid of the same query would not be the same in
the master and the standby servers, we cannot associate those two statistics
by using the queryid. The queryid changes through the crash recovery, so
we cannot associate the query statistics generated before the crash with that
generated after the crash recovery even if the query is the same.

This is not directly related to the patch itself, but why does the queryid
need to be calculated based on also the "statistics session"?

>> Will update documentation
>> clearly explain the term statistics session in this context

Yep, that's helpful!

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-09-19 08:24:34 Re: logical changeset generation v6
Previous Message Jeevan Chalke 2013-09-19 06:00:18 Re: proposal: simple date constructor from numeric values