On Thu, May 4, 2017 at 10:20 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > Now I'm not going to pretend that this patch is ready for the > prime-time. I've not yet worked out how to properly report sync-scan > locations without risking reporting later pages after reporting the > end of the scan. What I have at the moment could cause a report to be > missed if SYNC_SCAN_REPORT_INTERVAL is not divisible by the batch > size. I'm also not sure how batching like this affect read-aheads, but > at least the numbers above speak for something. Although none of the > pages in this case came from disk.
This kind of approach has also been advocated within EnterpriseDB, and I immediately thought of the read-ahead problem. I think we need more research into how Parallel Seq Scan interacts with OS readahead behavior on various operating systems. It seem possible that Parallel Seq Scan frustrates operating system read-ahead even without this change on at least some systems (because maybe they can only detect ascending block number requests within a single process) and even more possible that you run into problems with the block number requests are no longer precisely in order (which, at present, they should be, or very close). If it turns out to be a problem, either currently or with this patch, we might need to add explicit prefetching logic to Parallel Seq Scan. -- 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