Robert Haas wrote:
> > Actually, we *do* have some idea which tables are hot. ?Or at least, we
> > could. ? Currently, pg_stats for tables are "timeless"; they just
> > accumulate from the last reset, which has always been a problem in
> > general for monitoring. ?If we could make top-level table and index
> > stats time-based, even in some crude way, we would know which tables
> > were currently hot. ?That would also have the benefit of making server
> > performance analysis and autotuning easier.
> I think there would be value in giving the DBA an easier way to see
> which tables are hot, but I am really leery about the idea of trying
> to feed that directly into the query planner.  I think this is one of
> those cases where we let people tune it manually for starters, and
> then wait for feedback.  Eventually someone will say "oh, I never tune
> that by hand any more, ever since I wrote this script which does the
> following computation... and I just run it out cron".  And then we
> will get out the party hats.  But we will never get the experience we
> need to say what that auto-tuning algorithm will be unless we first
> provide the knob for someone to fiddle with manually.

It is also possible we will implement a manual way and never get around
to automating it.   :-(

  Bruce Momjian  <>

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to