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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to