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

<p dir="ltr"><br /> On Sep 30, 2013 4:39 AM, "Sameer Thakur" <<a
href="mailto:samthakur74@gmail.com">samthakur74@gmail.com</a>>wrote:<br /> ><br /> > > Also, for onlookers,
Ihave changed this patch around to do the <br /> > > date-oriented stuff but want to look it over before stapling
itup and <br /> > > sending it.  If one cannot wait, one can look at <br /> > > <a
href="https://github.com/fdr/postgres/tree/queryid">https://github.com/fdr/postgres/tree/queryid</a>. The
squashed-versionof <br /> > > that history contains a reasonable patch I think, but a re-read often <br /> >
>finds something for me and I've only just 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 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 /> >      10 | 12900 | 2013-09-30
16: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
understandsession_start and verified that it changes with each <br /> > database restart to reflect current time.<p
dir="ltr">Itshould only restart when the statistics file cannot be loaded.<p dir="ltr"> I am not sure why introduced
<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 statistics is added <br /> > to hashtable. Is this a bug? <br /> > Will continue to
testand try and understand the code. <p dir="ltr">Yes, a bug.  There are a few calls to pgss store and I must be
submittinga zero value for the introduction time in one of those cases.<p dir="ltr">Heh, I thought that was fixed, but
maybeI broke something.  Like I said; preliminary. At the earliest I can look at this Wednesday, but feel free to amend
andresubmit including my changes if you feel inclined and get to it first.