Re: Tracking last scan time
От | Dave Page |
---|---|
Тема | Re: Tracking last scan time |
Дата | |
Msg-id | CA+OCxoxsjFDQ3_hSBmvgB4qV2RN4bEvBDp+GdQmQr97zLSrHgA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tracking last scan time (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Tracking last scan time
|
Список | pgsql-hackers |
On Wed, 31 Aug 2022 at 17:13, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Aug 31, 2022 at 05:02:33PM +0100, Dave Page wrote:
>
>
> On Tue, 30 Aug 2022 at 19:46, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Fri, Aug 26, 2022 at 02:05:36PM +0100, Dave Page wrote:
> > On Thu, 25 Aug 2022 at 01:44, David Rowley <dgrowleyml@gmail.com> wrote:
> > I don't have a particular opinion about the patch, I'm just pointing
> > out that there are other ways. Even just writing down the numbers on
> a
> > post-it note and coming back in a month to see if they've changed is
> > enough to tell if the table or index has been used.
> >
> >
> > There are usually other ways to perform monitoring tasks, but there is
> > something to be said for the convenience of having functionality built in
> and
> > not having to rely on tools, scripts, or post-it notes :-)
>
> Should we consider using something cheaper like time() so we don't need
> a GUC to enable this?
>
>
> Interesting idea, but on my mac at least, 100,000,000 gettimeofday() calls
> takes about 2 seconds, whilst 100,000,000 time() calls takes 14(!) seconds.
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().
В списке pgsql-hackers по дате отправления: