RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Andrei Zubkov' <zubkov(at)moonset(dot)ru>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2021-03-23 02:13:25
Message-ID: OSBPR01MB315755D7AB3208D9BE32B81CF5649@OSBPR01MB3157.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Andrei,

I think the idea is good because the pg_stat_statements_info view cannot distinguish
whether the specific statement is deallocated or not.
But multiple calling of GetCurrentTimestamp() may cause some performance issues.
How about adding a configuration parameter for controlling this feature?
Or we don't not have to worry about that?

> + if (api_version >= PGSS_V1_9)
> + {
> + values[i++] = TimestampTzGetDatum(first_seen);
> + }

I think {} is not needed here.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-23 02:13:43 Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)
Previous Message tsunakawa.takay@fujitsu.com 2021-03-23 02:01:56 RE: [POC] Fast COPY FROM command for the table with foreign partitions