Robert Haas wrote:
> On Sat, Feb 26, 2011 at 1:57 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > 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. ? :-(
>
> You make it sound as if we know how but are just too lazy to right the
> code. That is not one of the weaknesses that this community has.
Well, several automatic idea have been floated, but rejected because
they don't work well for queries that are planned and executed later.
Perhaps we should consider auto-tuning of queries that are planned for
immediate execution. I just posed that idea in an email to this thread.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +