public inbox for [email protected]  

help / color / mirror / Atom feed

Proposal: Track last-used timestamp for index usage
3+ messages / 3 participants
[nested] [flat]

* Proposal: Track last-used timestamp for index usage
@ 2026-04-01 02:22 Raghav Mittal <[email protected]>
  2026-04-01 02:50 ` Re: Proposal: Track last-used timestamp for index usage SATYANARAYANA NARLAPURAM <[email protected]>
  2026-04-01 02:58 ` Re: Proposal: Track last-used timestamp for index usage Sami Imseih <[email protected]>
  0 siblings, 2 replies; 3+ messages in thread

From: Raghav Mittal @ 2026-04-01 02:22 UTC (permalink / raw)
  To: pgsql-hackers

Hi all,

I’ve been exploring index usage statistics in PostgreSQL and noticed that
pg_stat_user_indexes only provides cumulative counters (idx_scan), but not
recency information.

Problem:
- Counters reset on restart or pg_stat_reset()
- No way to determine when an index was last used
- Makes it hard to safely identify unused indexes

Proposal:
Introduce lightweight tracking of last-used timestamp for indexes.

Possible approach:
- Mark index usage in executor (cheap signal)
- Background worker periodically updates last_used_at
- Avoids overhead in query execution path

Questions:
1. Has this problem been explored before?
2. Are there known concerns with adding timestamp tracking to stats?
3. Would this be acceptable as an extension vs core feature?

Happy to prototype this if there’s interest.

Thanks!


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Proposal: Track last-used timestamp for index usage
  2026-04-01 02:22 Proposal: Track last-used timestamp for index usage Raghav Mittal <[email protected]>
@ 2026-04-01 02:50 ` SATYANARAYANA NARLAPURAM <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: SATYANARAYANA NARLAPURAM @ 2026-04-01 02:50 UTC (permalink / raw)
  To: Raghav Mittal <[email protected]>; +Cc: pgsql-hackers

Hi Raghav,

On Tue, Mar 31, 2026 at 7:23 PM Raghav Mittal <[email protected]> wrote:

> Hi all,
>
> I’ve been exploring index usage statistics in PostgreSQL and noticed that
> pg_stat_user_indexes only provides cumulative counters (idx_scan), but not
> recency information.
>
> Problem:
> - Counters reset on restart or pg_stat_reset()
> - No way to determine when an index was last used
> - Makes it hard to safely identify unused indexes
>
> Proposal:
> Introduce lightweight tracking of last-used timestamp for indexes.
>

Could you elaborate the problem trying to solve here? As you mentioned
idx_scan already tracks the usage. Periodic snapshots should provide the
usage over a period of time. What is the purpose of exact timestamp?

Thanks,
Satya


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Proposal: Track last-used timestamp for index usage
  2026-04-01 02:22 Proposal: Track last-used timestamp for index usage Raghav Mittal <[email protected]>
@ 2026-04-01 02:58 ` Sami Imseih <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: Sami Imseih @ 2026-04-01 02:58 UTC (permalink / raw)
  To: Raghav Mittal <[email protected]>; +Cc: pgsql-hackers

Hi,

> I’ve been exploring index usage statistics in PostgreSQL and noticed that
> pg_stat_user_indexes only provides cumulative counters (idx_scan), but not
> recency information.

pg_stat_user_indexes.last_idx_scan and pg_stat_all_tableslast_seq_scan have been
around since v16. See [1]

Is that what you are looking for?

[1] [https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW]

--
Sami Imseih
Amazon Web Services (AWS)





^ permalink  raw  reply  [nested|flat] 3+ messages in thread

end of thread, other threads:[~2026-04-01 02:58 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-01 02:22 Proposal: Track last-used timestamp for index usage Raghav Mittal <[email protected]>
2026-04-01 02:50 ` SATYANARAYANA NARLAPURAM <[email protected]>
2026-04-01 02:58 ` Sami Imseih <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox