Re: pg_stat_statements: calls under-estimation propagation
От | Sameer Thakur |
---|---|
Тема | Re: pg_stat_statements: calls under-estimation propagation |
Дата | |
Msg-id | CABzZFEuBVBO+GrNvNo4qLqUXv_a-QwTfiRRK7ipc=oK0vwGbqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_statements: calls under-estimation propagation (Daniel Farina <daniel@fdr.io>) |
Список | 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 />
В списке pgsql-hackers по дате отправления: