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

> Also, for onlookers, I have changed this patch around to do the <br />> date-oriented stuff but want to look it
overbefore stapling it up and <br />> sending it.  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 history
containsa reasonable patch I think, but a re-read often <br />> finds something for me and I've only just completed
ityesterday. <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 understand session_start and verified that it changes with each <br />database restart to
reflectcurrent time. I am not sure why introduced <br />keeps showing the same "1970-01-01 05:30:00+05:30" value. I
thoughtit <br />reflected the (most recent) time query statements statistics is added <br />to hashtable. Is this a
bug?<br />Will continue to test and try and understand the code. <br /><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-tp5738128p5772841.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 />