On Wed, 15 Jul 2020 at 14:51, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jul 15, 2020 at 5:55 AM David Rowley <dgrowle...@gmail.com> wrote: > > If we've not seen any performance regressions within 1 week, then I > > propose that we (pending final review) push this to allow wider > > testing. > > I think Soumyadeep has reported a regression case [1] with the earlier > version of the patch. I am not sure if we have verified that the > situation improves with the latest version of the patch. I request > Soumyadeep to please try once with the latest patch.
Yeah, it would be good to see some more data points on that test. Jumping from 2 up to 6 workers just leaves us to guess where the performance started to become bad. It would be good to know if the regression is repeatable or if it was affected by some other process. I see the disk type on that report was Google PersistentDisk. I don't pretend to be any sort of expert on network filesystems, but I guess a regression would be possible in that test case if say there was an additional layer of caching of very limited size between the kernel cache and the disks, maybe on a remote machine. If it were doing some sort of prefetching to try to reduce latency and requests to the actual disks then perhaps going up to 6 workers with 64 chunk size (as Thomas' patch used at that time) caused more cache misses on that cache due to the requests exceeding what had already been prefetched. That's just a stab in the dark. Maybe someone with knowledge of these network file systems can come up with a better theory. It would be good to see EXPLAIN (ANALYZE, BUFFERS) with SET track_io_timing = on; for each value of max_parallel_workers. David > [1] - > https://www.postgresql.org/message-id/CADwEdoqirzK3H8bB%3DxyJ192EZCNwGfcCa_WJ5GHVM7Sv8oenuA%40mail.gmail.com