From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Tracking last scan time |
Date: | 2022-09-01 12:18:00 |
Message-ID: | CA+OCxoyrRgz+fQ_i0kYYwYVvf0qfxbeGH1AjZci0FrUT9Gx38Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 1 Sept 2022 at 13:04, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Sep 1, 2022 at 09:46:59AM +0100, Dave Page wrote:
> > On Wed, 31 Aug 2022 at 17:13, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Wow. I was just thinking you need second-level accuracy, which must
> be
> > cheap somewhere.
> >
> >
> > Second-level accuracy would indeed be fine for this. Frankly, for my use
> case
> > just the date would be enough, but I can imagine people wanting greater
> > accuracy than that.
> >
> > And yes, I was very surprised by the timing results I got as well. I
> guess it's
> > a quirk of macOS - on a Linux box I get ~4s for gettimeofday() and ~1s
> for time
> > ().
>
> i think we lose 95% of our users if we require it to be enabled so let's
> work to find a way it can be always enabled.
>
So based on Andres' suggestion, something like this seems like it might
work:
if (pgstat_track_scan_timestamps && lstats->t_counts.t_numscans)
{
TimestampTz t = GetCurrentTransactionStopTimestamp();
if (t > tabentry->lastscan)
tabentry->lastscan = t;
}
If that seems like a good option, I can run some more benchmarks (and then
remove the GUC if it looks good).
--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2022-09-01 12:18:42 | Re: Tracking last scan time |
Previous Message | Daniel Gustafsson | 2022-09-01 12:14:52 | Re: [PATCH v1] fix potential memory leak in untransformRelOptions |