On 1/28/15 7:27 PM, Stephen Frost wrote:
> * Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
>> >On 1/28/15 9:56 AM, Stephen Frost wrote:
>>> > >Such i/o systems do exist, but a single RAID5 group over spinning rust
>>> > >with a simple filter isn't going to cut it with a modern CPU- we're just
>>> > >too darn efficient to end up i/o bound in that case. A more complex
>>> > >filter might be able to change it over to being more CPU bound than i/o
>>> > >bound and produce the performance improvments you're looking for.
>> >
>> >Except we're nowhere near being IO efficient. The vast difference between Postgres IO rates and dd shows this. I
suspectthat's because we're not giving the OS a list of IO to perform while we're doing our thing, but that's just a
guess.
> Uh, huh? The dd was ~321000 and the slowest uncached PG run from
> Robert's latest tests was 337312.554, based on my inbox history at
> least. I don't consider ~4-5% difference to be vast.
Sorry, I was speaking more generally than this specific test. In the past I've definitely seen SeqScan performance that
wasan order of magnitude slower than what dd would do. This was an older version of Postgres and an older version of
linux,running on an iSCSI SAN. My suspicion is that the added IO latency imposed by iSCSI is what was causing this, but
that'sjust conjecture.
I think Robert was saying that he hasn't been able to see this effect on their test server... that makes me think it's
doingread-ahead on the OS level. But I suspect it's pretty touch and go to rely on that; I'd prefer we have some way to
explicitlyget that behavior where we want it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com