On 1/28/15 7:27 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@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 suspect that'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 was an 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's just 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 doing read-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 explicitly get that behavior where we want it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
