> 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.
I'm not disagreeing with that. I'm saying "first, we give DBAs a way to
see which tables are currently hot". Such a feature has multiple
benefits, making it worth the overhead and/or coding effort.
Whether we're shooting for autotuning or manual tuning, it starts with
having the data.
-- Josh Berkus
PostgreSQL Experts Inc.
In response to
pgsql-hackers by date
|Next:||From: Anton||Date: 2011-02-27 22:31:47|
|Subject: Fwd: Re: Native XML|
|Previous:||From: Rémi Zara||Date: 2011-02-27 21:56:28|
|Subject: Re: pika failing since the per-column collation patch|