Re: Tracking last scan time - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Tracking last scan time
Date
Msg-id Yw+IsSDlUhbjFiZO@momjian.us
Whole thread Raw
In response to Re: Tracking last scan time  (Dave Page <dpage@pgadmin.org>)
Responses Re: Tracking last scan time
List pgsql-hackers
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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson




pgsql-hackers by date:

Previous
From: Reid Thompson
Date:
Subject: Bug fix. autovacuum.c do_worker_start() associates memory allocations with TopMemoryContext rather than 'Autovacuum start worker (tmp)'
Next
From: Andres Freund
Date:
Subject: Re: Tracking last scan time