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