On Apr 27, 2011, at 11:01 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > The patch may be simple, the testing not so much. I know that. > > What tools do we have to do that testing? There are lots, and all > imply a lot of work. Is that work worth the trouble? Because if it > is... why not work? > > I would propose a step in the right direction: a patch to compute and > log periodical estimations of the main I/O tunables: random_page_cost, > sequential_page_cost and effective_cache_size. Maybe per-tablespace. > Evaluate the performance impact, and work from there. > > Because, probably just using those values as input to the optimizer > won't work, because dbas will want a way to tune the optimizer, > because the system may not be stable enough, even because even with > accurate estimates for those values, the optimizer may not perform as > expected. I mean, right now those values are tunables, not real > metrics, so perhaps the optimizer won't respond well to real values. > > But having the ability to measure them without a serious performance > impact is a step in the right direction, right?
Sure. It's not a real easy problem, but don't let that discourage you from working on it. Getting more eyeballs on these issues can only be a good thing. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
