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

From Dave Page
Subject Re: Tracking last scan time
Date
Msg-id CA+OCxoyW+T=xUdehU=oDcHeK-qw7ToaSvy0aOpbdWAa4Q_iL4w@mail.gmail.com
Whole thread Raw
In response to Re: Tracking last scan time  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Tracking last scan time
List pgsql-hackers


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.

--

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SQL/JSON features for v15
Next
From: Reid Thompson
Date:
Subject: Add tracking of backend memory allocated to pg_stat_activity