On Sat, Feb 26, 2011 at 1:57 AM, Bruce Momjian <br...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to