The more I think about this thread, the more I'm convinced of 2 things:
1= Suggesting initial config values is a fundamentally different
exercise than tuning a running DBMS.
This can be handled reasonably well by HW and OS snooping. OTOH,
detailed fine tuning of a running DBMS does not appear to be amenable
to this approach.
So...
2= We need to implement the kind of timer support that Oracle 10g has.
Oracle performance tuning was revolutionized by there being
micro-second accurate timers available for all Oracle operations.
IMHO, we should learn from that.
Only the combination of the above looks like it will really be
successful in addressing the issues brought up in this thread.
Cheers,
Ron Peacetree
At 01:59 PM 4/27/2007, Josh Berkus wrote:
Dan,
> Exactly.. What I think would be much more productive is to use the
> great amount of information that PG tracks internally and auto-tune the
> parameters based on it. For instance:
*Everyone* wants this. The problem is that it's very hard code to write
given the number of variables. I'm working on it but progress is slow,
due to my travel schedule.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
