On Wed, Jan 28, 2015 at 8:27 PM, Stephen Frost <sfr...@snowman.net> wrote: > I feel like one of us is misunderstanding the numbers, which is probably > in part because they're a bit piecemeal over email, but the seqscan > speed in this case looks pretty close to dd performance for this > particular test, when things are uncached. Cached numbers are > different, but that's not what we're discussing here, I don't think. > > Don't get me wrong- I've definitely seen cases where we're CPU bound > because of complex filters, etc, but that doesn't seem to be the case > here.
To try to clarify a bit: What we've testing here is a function I wrote called parallel_count(regclass), which counts all the visible tuples in a named relation. That runs as fast as dd, and giving it extra workers or prefetching or the ability to read the relation with different I/O patterns never seems to speed anything up very much. The story with parallel sequential scan itself may well be different, since that has a lot more CPU overhead than a dumb-simple tuple-counter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
