On Apr 27, 2011, at 11:01 PM, Claudio Freire <klaussfreire(at)gmail(dot)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.
In response to
pgsql-performance by date
|Next:||From: Tatsuo Ishii||Date: 2011-04-30 01:27:51|
|Subject: Re: pgpoolAdmin handling several pgpool-II clusters|
|Previous:||From: Robert Haas||Date: 2011-04-29 23:00:23|
|Subject: Re: Performance|