RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements - Mailing list pgsql-hackers

From kuroda.hayato@fujitsu.com
Subject RE: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date
Msg-id OSBPR01MB315755D7AB3208D9BE32B81CF5649@OSBPR01MB3157.jpnprd01.prod.outlook.com
Whole thread Raw
In response to [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
Responses Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Andrei Zubkov <zubkov@moonset.ru>)
List 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


pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [POC] Fast COPY FROM command for the table with foreign partitions
Next
From: Tom Lane
Date:
Subject: Re: Handling of opckeytype / CREATE OPERATOR CLASS (bug?)