Bruce Momjian wrote:
> Greg Smith wrote:

> I don't expect this patch to be perfect when it is applied. I do expect
> to be a best effort, and it will get continual real-world testing during
> beta and we can continue to improve this. Right now, we know we have a
> serious issue with checkpoint I/O, and this patch is going to improve
> that in most cases. I don't want to see us reject it or greatly delay
> beta as we try to make it perfect.
>
> My main point is that should keep trying to make the patch better, but
> the patch doesn't have to be perfect to get applied. I don't want us to
> get into a death-by-testing spiral.

Death by testing? The only comment I have is that is could be useful to
be able to turn this feature off via GUC. Other than that, I think it is
great.

Joshua D. Drake


>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Joshua D. Drake wrote:
> The only comment I have is that is could be useful to
> be able to turn this feature off via GUC. Other than that, I think it is
> great.

Yeah, you can do that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

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

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

On Wed, 20 Jun 2007, Bruce Momjian wrote:

> I don't expect this patch to be perfect when it is applied. I do expect
> to be a best effort, and it will get continual real-world testing during
> beta and we can continue to improve this.

This is completely fair. Consider my suggestions something that people
might want look out for during beta rather than a task Heikki should worry
about before applying the patch.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend