Query the cache hit with:

SELECT
sum(heap_blks_read) as heap_read,
sum(heap_blks_hit) as heap_hit,
sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio
FROM
pg_statio_user_tables;

For Bridge customers, cache hit data is in your clusters insights.

Parameter | Value
---------------------------------+----------------------------------------------
TimeZone | America/Chicago
application_name | psql
client_encoding | UTF8
lock_timeout | 10s

The command to reset pg_stat_statements is:
SELECT pg_stat_statements_reset();

4) After major maintenance operations
Resetting pg_stat_statements after major operations (pg_repack, reindexes, altering table structures, etc) helps to measure how any changes affect performance.

3) When benchmarking query performance
If you are running benchmarks and tests to evaluate query improvements, resetting pg_stat_statements makes sure that your results reflect only the queries executed during the benchmark periods.

It will also help accuracy of reports (for example, the outliers insight) by preventing old, outdated queries from skewing the results.

2) After deploying significant query changes
If you have made significant changes to an app, optimized queries, or modified indexes, resetting pg_stat_statements helps to measure the impact of those changes more accurately.

1) At the start of a new monitoring period
If you analyze performance trends daily, weekly, or monthly, resetting pg_stat_statements at the beginning of such a period helps ensure that each period starts with a clean dataset.