On Sun, 4 May 2008, Tom Lane wrote:
> Well, I tried a pgbench test similar to that one --- on smaller hardware
> than was re****ted, so it was a bit smaller test case, but it should have
> given similar results.
My pet theory on cases where sorting will help suggests you may need a
write-caching controller for this patch to be useful. I expect we'll see
the biggest improvement in situations where the total amount of dirty
buffers is larger than the write cache and the cache becomes blocked. If
you're not offloading to another device like that, the OS-level elevator
sorting will handle sorting for you close enough to optimally that I doubt
this will help much (and in fact may just get in the way).
> Of course it's notoriously hard to get consistent numbers out of pgbench
> anyway, so I'd rather see some other test case ...
I have some tools to run pgbench results many times and look for patterns
that work fairly well for the consistency part. pgbench will dirty a very
high percentage of the buffer cache by checkpoint time relative to how
much work it does, which makes it close to a best case for confirming
there is a potential improvement here.
I think a reasonable approach is to continue trying to quantify some
improvement using pgbench with an eye toward also doing DBT2 tests, which
provoke similar behavior at checkpoint time. I suspect someone who
already has a known good DBT2 lab setup with caching controller hardware
(EDB?) might be able to do a useful test of this patch without too much
trouble on their part.
> Unless someone can volunteer to test sooner, I think we should drop this
> item from the current commitfest queue.
This patch took a good step forward toward being commited this round with
your review, which is the im****tant part from my perspective (as someone
who would like this to be committed if it truly works). I expect that
performance related patches will often take more than one commitfest to
pass through.
From the perspective of keeping the committer's plates clean, a reasonable
system for this situation might be for you to bounce this into the
rejected pile as "Returned for testing" immediately, to clearly remove it
from the main queue. A reasonable expectation there is that you might
consider it again during May if someone gets back with said testing
results before the 'fest ends.
--
* Greg Smith gsmith@[EMAIL PROTECTED]
http://www.gregsmith.com
Baltimore, MD
--
Sent via pgsql-patches mailing list (pgsql-patches@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
|
