Re: Exposing the stats snapshot timestamp to SQL
| От | Matt Kelly |
|---|---|
| Тема | Re: Exposing the stats snapshot timestamp to SQL |
| Дата | |
| Msg-id | CA+KcUkh4R7hGiyB1=0i9ZC-JnCg9+T=cbEuv+7DkzJA3aB9vbg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Exposing the stats snapshot timestamp to SQL (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: Exposing the stats snapshot timestamp to SQL
Re: Exposing the stats snapshot timestamp to SQL |
| Список | pgsql-hackers |
Robert, I'll add it to the commitfest.
Jim, I'm not sure I understand what you mean? This new function follows the same conventions as everything else in the file. TimestampTz is just a typedef for int64. Functions like pg_stat_get_buf_alloc follow the exact same pattern on the int64 fields of the global stats struct.
- Matt K.
On Thu, Jan 29, 2015 at 6:49 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 1/28/15 11:18 PM, Matt Kelly wrote:In a previous thread Tom Lane said:
(I'm also wondering if it'd make sense to expose the stats timestamp
as a callable function, so that the case could be dealt with
programmatically as well. But that's future-feature territory.)
(http://www.postgresql.org/message-id/27251.1421684169@sss.pgh.pa.us)
It seemed the appropriate scope for my first submission, and that feature has been on my wish list for a while, so I thought I'd grab it.
I've reviewed the patch (though haven't tested it myself) and it looks good. The only thing I'm not sure of is this:
+ /* Get the timestamp of the current statistics snapshot */
+ Datum
+ pg_stat_snapshot_timestamp(PG_FUNCTION_ARGS)
+ {
+ PG_RETURN_TIMESTAMPTZ(pgstat_fetch_global()->stats_timestamp);
+ }
Is the community OK with referencing stats_timestamp that way?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: