Hi Kuroda,
Thank you for your attention!
On Tue, 2021-03-23 at 02:13 +0000, kuroda.hay...@fujitsu.com wrote:
> 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?
Certaily I was thinking about this. And I've taken an advice of Teodor
Sigaev - a much more expirienced developer than me. It seems that
GetCurrentTimestamp() is fast enough for our purpose and we won't call
it too often - only on new statement entry allocation.
By the way right now in my workload tracing tool pg_profile I have to
reset pg_stat_statements on every sample (wich is about 30-60 minutes)
to make sure that all workload between samples is captured. This causes
much more overhead. Introduced first_seen column can eliminate the need
of resets.
However, there is another way - we can store the curent value
of pg_stat_statements_info.dealloc field when allocating a new
statement entry instead of timstamping it. Probably, it would be little
faster, but timestamp seems much more valuable here.
>
> > + if (api_version >= PGSS_V1_9)
> > + {
> > + values[i++] = TimestampTzGetDatum(first_seen);
> > + }
>
> I think {} is not needed here.
Of course, thank you!
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
