Simon Riggs <simon@2ndquadrant.com> writes:
> This was supposed to be a serious suggestion, so apologies if this came
> across stronger than it was meant.

If you want to have a serious discussion about it, you need to start a
thread on pghackers under a more suitable subject line. The people
reading this thread are going to be a relatively small group.

regards, tom lane

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

Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
>
>>Tom Lane wrote:
>>
>>>Sounds like a recipe for ensuring it never will be tested. What's
>>>needed here is some actual tests, not preparation...
>
>
>>Does the OP have a test scenario that those of us with appropriate OS's
>>could try? Come to think of it, what are the appropriate OS's? (I see
>>NetBSD mentioned so I suppose all the *BSDs, but what others?).
>
>
> The test run by the OP was just pgbench,

Ah - right, missed that sorry.

> which is probably not the
> greatest scenario for showing the benefits of this patch, but at least
> it's neutral ground. You need a situation in which the kernel is under
> memory stress, else early free of disk cache buffers isn't going to make
> any difference whatever --- so choose a pgbench scale factor that makes
> the database noticeably larger than the test machine's RAM. Other than
> that, follow the usual guidelines for producing trustworthy pgbench
> numbers: number of clients smaller than scale factor, number of
> transactions per client at least 1000 or so (to eliminate startup
> transients), repeat test a couple times to make sure numbers are
> reproducible.
>

Thinking about this, presumably any write intensive, multi-user
benchmark would seem to be suitable, so would something like OSDL's
DBT-2 actually be better to try?

Cheers

Mark

(P.s - academic in my case, unless I try out the latest NetBSD or Linux
on one of my FreeBSD boxes....)

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

Mark Kirkwood <markir@paradise.net.nz> writes:
> Thinking about this, presumably any write intensive, multi-user
> benchmark would seem to be suitable, so would something like OSDL's
> DBT-2 actually be better to try?

I'm certainly not wedded to pgbench, give it a try.

BTW, I forgot to mention that it would be useful to try different
wal_sync_methods along with this. The reason why it seems unlikely
the patch is useful on Linux is that the sync methods that use O_DIRECT
probably dominate using the patch anyway. There may or may not be
a similar dependence on sync method on other kernels ...

regards, tom lane

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

Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
> > Thinking about this, presumably any write intensive, multi-user
> > benchmark would seem to be suitable, so would something like OSDL's
> > DBT-2 actually be better to try?
>
> I'm certainly not wedded to pgbench, give it a try.
>
> BTW, I forgot to mention that it would be useful to try different
> wal_sync_methods along with this. The reason why it seems unlikely
> the patch is useful on Linux is that the sync methods that use O_DIRECT
> probably dominate using the patch anyway. There may or may not be
> a similar dependence on sync method on other kernels ...

I am thinking the only way to test this would be to do one heavy update
session to generate a lot of WAL traffic, and another session that is
doing a sequential scan on a table that fills most of the cache. It
isn't an easy test to make, which was why I was thinking we just add the
patch, but the community disagrees.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(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