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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
