Re: Tracking last scan time
От | Dave Page |
---|---|
Тема | Re: Tracking last scan time |
Дата | |
Msg-id | CA+OCxoyrRgz+fQ_i0kYYwYVvf0qfxbeGH1AjZci0FrUT9Gx38Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tracking last scan time (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Thu, 1 Sept 2022 at 13:04, Bruce Momjian <bruce@momjian.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@momjian.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:
{
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).
В списке pgsql-hackers по дате отправления: