Re: Tracking last scan time

On Wed, 31 Aug 2022 at 17:13, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)gmail(dot)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().

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com