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

On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL] <br /><<a
href="/user/SendEmail.jtp?type=node&node=5772930&i=0"link="external" rel="nofollow" target="_top">[hidden
email]</a>>wrote: <div class="shrinkable-quote"><br />> <br />> On Sep 30, 2013 4:39 AM, "Sameer Thakur"
<[hiddenemail]> wrote: <br />>> <br />>> > Also, for onlookers, I have changed this patch around
todo the <br />>> > date-oriented stuff but want to look it over before stapling it up and <br />>> >
sendingit.  If one cannot wait, one can look at <br />>> > <a
href="https://github.com/fdr/postgres/tree/queryid"link="external" rel="nofollow"
target="_top">https://github.com/fdr/postgres/tree/queryid</a>. The squashed-version of <br />>> > that
historycontains a reasonable patch I think, but a re-read often <br />>> > finds something for me and I've
onlyjust completed it yesterday. <br />>> > <br />>> <br />>> I did the following <br />>>
1.Forked from fdr/postgres <br />>> 2. cloned branch queryid <br />>> 3. squashed <br />>>
22899c802571a57cfaf0df38e6c5c366b5430c74<br />>> d813096e29049667151a49fc5e5cf3d6bbe55702 <br />>> picked
<br/>>> be2671a4a6aa355c5e8ae646210e6c8e0b84ecb5 <br />>> 4. usual make/make install/create extension
pg_stat_statements.<br />>> (pg_stat_statements.max=100). <br />>> 5. select * from
pg_stat_statements_reset(),select * from <br />>> pgbench_tellers. <br />>> result below: <br />>>
<br/>>> userid | dbid  |          session_start           |        introduced <br />>>        |            
     query                   |      query_id <br />>>   | calls | total_time | <br />>>  rows |
shared_blks_hit| shared_blks_read | shared_blks_dirtied | <br />>> shared_blks_written | local_blks_hit |
local_blks_read| <br />>> local_blks_dirtied | local_blks_written | t <br />>> emp_blks_read |
temp_blks_written| blk_read_time | blk_write_time <br />>> <br />>>
--------+-------+----------------------------------+---------------------------+-------------------------------------------+---------------------+-------+------------+
<br/>>> <br />>>
------+-----------------+------------------+---------------------+---------------------+----------------+-----------------+--------------------+--------------------+--
<br/>>> --------------+-------------------+---------------+---------------- <br />>>      10 | 12900 |
2013-09-3016:55:22.285113+05:30 | 1970-01-01 <br />>> 05:30:00+05:30 | select * from pg_stat_statements_reset();
|<br />>> 2531907647060518039 |     1 |          0 | <br />>>     1 |               0 |                0 |
                 0 | <br />>>               0 |              0 |               0 | <br />>> 0 |            
    0 | <br />>>             0 |                 0 |             0 |              0 <br />>>      10 |
12900| 2013-09-30 16:55:22.285113+05:30 | 1970-01-01 <br />>> 05:30:00+05:30 | select * from pgbench_tellers ;  
       | <br />>> 7580333025384382649 |     1 |          0 | <br />>>    10 |               1 |            
  0 |                   0 | <br />>>               0 |              0 |               0 | <br />>> 0 |    
            0 | <br />>>             0 |                 0 |             0 |              0 <br />>> (2
rows)<br />>> <br />>> <br />>> I understand session_start and verified that it changes with each <br
/>>>database restart to reflect current time. <br />> <br />> It should only restart when the statistics
filecannot be loaded. <br />> <br />> I am not sure why introduced <br />> <br />>> keeps showing the
same"1970-01-01 05:30:00+05:30" value. I thought it <br />>> reflected the (most recent) time query statements
statisticsis added <br />>> to hashtable. Is this a bug? <br />>> Will continue to test and try and
understandthe code. <br />> <br />> Yes, a bug.  There are a few calls to pgss store and I must be submitting a
<br/>> zero value for the introduction time in one of those cases. <br />> <br />> Heh, I thought that was
fixed,but maybe I broke something.  Like I said; <br />> preliminary. At the earliest I can look at this Wednesday,
butfeel free to <br />> amend and resubmit including my changes if you feel inclined and get to it <br />> first.
</div><br/>In pg_stat_statements.c line 1440 <br />changed <br />if (instr == NULL) <br />to <br />if (instr == NULL ||
INSTR_TIME_IS_ZERO(instr->starttime))<br /><br />This seemed to do the trick. I will continue to test some more. <br
/>regards<br />Sameer <br /><br /><hr align="left" width="300" /> View this message in context: <a
href="http://postgresql.1045698.n5.nabble.com/pg-stat-statements-calls-under-estimation-propagation-tp5738128p5772930.html">Re:
pg_stat_statements:calls under-estimation propagation</a><br /> Sent from the <a
href="http://postgresql.1045698.n5.nabble.com/PostgreSQL-hackers-f1928748.html">PostgreSQL- hackers mailing list
archive</a>at Nabble.com.<br />