| From: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Is it possible to keep track of SELECTs? |
| Date: | 2024-03-12 15:34:17 |
| Message-ID: | CAFCRh-8GKecKL9ojzigBnS0qix80vOi0E0LujH5pd2CufVEpCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Mar 12, 2024 at 3:30 PM Christophe Pettus <xof(at)thebuild(dot)com> wrote:
> > On Mar 12, 2024, at 07:15, Dominique Devienne <ddevienne(at)gmail(dot)com>
> wrote:
> > So is it possible to track the last time a SELECT was performed on some
> TABLE?
>
> Directly, no. You could periodically sample the various table-level
> statistics, and conclude that tables that have had some type of scan since
> the last scan have had a SELECT run against them. It might not be 100%
> accurate if (for example) you reset the statistics or lose them for some
> other reason, but it might be sufficient for the application.
Bummer :(
PostgreSQL tables and indexes are ultimately files.
And there are ways to map them to file names, I've seen in the past.
So isn't it possible, provided the filesystem tracks last access time, to
infer when a table was accessed the last time?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2024-03-12 15:47:40 | Re: Is it possible to keep track of SELECTs? |
| Previous Message | Ron Johnson | 2024-03-12 15:30:45 | Re: Simple way to simulate a bug in logical replication |