On Wed, 20 Jun 2007, Heikki Linnakangas wrote:
> You mean the shift and "flattening" of the graph to the right in the delivery
> response time distribution graph?
Right, that's what ends up happening during the problematic cases. To
pick numbers out of the air, instead of 1% of the transactions getting
nailed really hard, by spreading things out you might have 5% of them get
slowed considerably but not awfully. For some applications, that might be
considered a step backwards.
> I'd like to understand the underlaying mechanism
I had to capture regular snapshots of the buffer cache internals via
pg_buffercache to figure out where the breakdown was in my case.
> I don't have any good simple ideas on how to make it better in 8.3 timeframe,
> so I don't think there's much to learn from repeating these tests.
Right now, it's not clear which of the runs represent normal behavior and
which might be anomolies. That's the thing you might learn if you had 10
at each configuration instead of just 1. The goal for the 8.3 timeframe
in my mind would be to perhaps have enough data to give better guidelines
for defaults and a range of useful settings in the documentation.
The only other configuration I'd be curious to see is pushing the number
of warehouses even more to see if the 90% numbers spread further from
current behavior.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
