Re: [Testperf-general] Re: ExclusiveLock - Mailing list pgsql-hackers

From Bort, Paul
Subject Re: [Testperf-general] Re: ExclusiveLock
Date
Msg-id 735D404BD9E7EB44B9CDFC27FC88809B0582D5FE@mail2.tmwsystems.com
Whole thread Raw
Responses Re: [Testperf-general] Re: ExclusiveLock  (Doug McNaught <doug@mcnaught.org>)
List pgsql-hackers
<p><font size="2">> The impression I had was that disk drives no longer pay the slightest</font><br /><font
size="2">>attention to interleave specs, because the logical model </font><br /><font size="2">> implied by
the</font><br/><font size="2">> concept is too far removed from modern reality (on-disk buffering,</font><br /><font
size="2">>variable numbers of sectors per track, transparently remapped bad</font><br /><font size="2">> sectors,
yaddayadda).</font><br /><font size="2">> </font><p><font size="2">Entirely true. Interleave was an issue back when
thecontroller wasn't fast enough to keep up with 3600 RPM disks, and is now completely obscured from the bus. I don't
knowif the ATA spec includes interleave control; I suspect it does not.</font><p><font size="2">> And that's just at
thehardware level ... who knows where the </font><br /><font size="2">> filesystem</font><br /><font size="2">>
isputting your data, or what the kernel I/O scheduler is doing with</font><br /><font size="2">> your requests
:-(</font><br/><font size="2">> </font><br /><font size="2">> Basically I see the TODO item as a blue-sky
researchtopic, not</font><br /><font size="2">> something we have any idea how to implement.  That doesn't
</font><br/><font size="2">> mean it can't</font><br /><font size="2">> be on the TODO list ...</font><br /><font
size="2">></font><p><font size="2">I think that if we also take into consideration various hardware and software
RAIDconfigurations, this is just too far removed from the database level to be at all practical to throw code
at.</font><p><fontsize="2">Perhaps this should be rewritten as a documentation change: recommendations about
performancehardware? What we recommend for our highest volume customers (alas, on a proprietary RDBMS, and only x86) is
somethinglike this:</font><p><font size="2">- Because drive capacity is so huge now, choose faster drives over larger
drives.15K RPM isn't three times faster than 5400, but there is a noticable difference. </font><p><font size="2">- More
spindlesreduce delays even further. Mirroring allows reads to happen faster because they can come from either side of
themirror, and spanning reduces problems with rotational delays.</font><p><font size="2">- The ideal disk configuration
thatwe recommend is a 14 drive chassis with a split backplane. Run each backplane to a separate channel on the
controller,and mirror the channels. Use the first drive on each channel for the OS and swap, the second drive for
transactionlogs, and the remaining drives spanned (and already mirrored) for data. With a reasonable write cache on the
controller,this has proven to be a pretty fast configuration despite a less than ideal engine.</font><p><font
size="2">Oneother thought: How does static RAM compare to disk speed nowadays? A 1Gb flash drive might be reasonable
forthe WAL if it can keep up. </font> 

pgsql-hackers by date:

Previous
From: Mike Rylander
Date:
Subject: Re: patch: plpgsql - access records with rec.(expr)
Next
From: Doug McNaught
Date:
Subject: Re: [Testperf-general] Re: ExclusiveLock