Skip site navigation (1) Skip section navigation (2)

Re: Performance

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance
Date: 2011-04-29 23:03:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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 IshiiDate: 2011-04-30 01:27:51
Subject: Re: pgpoolAdmin handling several pgpool-II clusters
Previous:From: Robert HaasDate: 2011-04-29 23:00:23
Subject: Re: Performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group