Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
Date
Msg-id CAA5RZ0u_jjiLc_w4nksdVazvvqtE17C1nM=sKf9fy5x02orfsg@mail.gmail.com
Whole thread Raw
In response to Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements  (Pavlo Golub <pavlo.golub@cybertec.at>)
List pgsql-hackers
> Thank you to Sami, Christoph, and Bertrand for the thorough review and valuable
> feedback on v1. I've prepared a v2 patch that addresses all the concerns raised.

Thanks for the patch! I have not looked at v2 in detail yet. Did take
a quick peek
at the doc. Some comments:

> I've renamed the column to `stats_last_updated` as Christoph suggested. This
> matches the existing "stats_since" column for consistency. Following Christoph's
> suggestion, I've also moved it to the end of the view.

I still wonder if "stats_last_updated" is a good name here. What about
"last_execution_start", since that is exactly what this timestamp is.

+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>stats_last_updated</structfield> <type>timestamp with
time zone</type>
+ </para>
+ <para>
+ Time at which the statement statistics were last updated (specifically,
+ the time when the statement most recently started execution).

Here I think we can just say:

"The start time of the most recent execution of the statement that completed. "

+ This is useful for monitoring tools to identify which statements
+ have been executed since their last poll.

I am not sure we need this part for the docs. others may disagree.

+ For nested statements (when <varname>pg_stat_statements.track</varname>
+ is set to <literal>all</literal>), this reflects the start time of the
+ parent top-level statement.
+ </para></entry>

Maybe this is better as it mentioned "toplevel"

"For nested statements (toplevel = false), this reflects the start time
of the top-level statement."

what do you think?

--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Marcos Magueta
Date:
Subject: Re: WIP - xmlvalidate implementation from TODO list
Next
From: Nathan Bossart
Date:
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible