On 06/26/2013 05:46 PM, Heikki Linnakangas wrote: > We could also allow a large query to search a single table in parallel. > A seqscan would be easy to divide into N equally-sized parts that can be > scanned in parallel. It's more difficult for index scans, but even then > it might be possible at least in some limited cases.
So far reading sequentially is still faster than hopping between different locations. Purely from the I/O perspective, that is. For queries where the single CPU core turns into a bottle-neck and which we want to parallelize, we should ideally still do a normal, fully sequential scan and only fan out after the scan and distribute the incoming pages (or even tuples) to the multiple cores to process. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
