On Thu, Mar 31, 2016 at 9:03 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > If you need some more information please let me know ?
I repeated the testing described in http://www.postgresql.org/message-id/ca+tgmoyouqf9cgcpgygngzqhcy-gcckryaqqtdu8kfe4n6h...@mail.gmail.com on a MacBook Pro (OS X 10.8.5, 2.4 GHz Intel Core i7, 8GB, early 2013) and got the following results. Note that I did not adjust *_flush_delay in this test because that's always 0, apparently, on MacOS. master, unlogged tables, 1 copy: 0m18.928s, 0m20.276s, 0m18.040s patched, unlogged tables, 1 copy: 0m20.499s, 0m20.879s, 0m18.912s master, unlogged tables, 4 parallel copies: 0m57.301s, 0m58.045s, 0m57.556s patched, unlogged tables, 4 parallel copies: 0m47.994s, 0m45.586s, 0m44.440s master, logged tables, 1 copy: 0m29.353s, 0m29.693s, 0m31.840s patched, logged tables, 1 copy: 0m30.837s, 0m31.567s, 0m36.843s master, logged tables, 4 parallel copies: 1m45.691s, 1m53.085s, 1m35.674s patched, logged tables, 4 parallel copies: 1m21.137s, 1m20.678s, 1m22.419s So the first thing here is that the patch seems to be a clear win in this test. For a single copy, it seems to be pretty much a wash. When running 4 copies in parallel, it is about 20-25% faster with both logged and unlogged tables. The second thing that is interesting is that we are getting super-linear scalability even without the patch: if 1 copy takes 20 seconds, you might expect 4 to take 80 seconds, but it really takes 60 unpatched or 45 patched. If 1 copy takes 30 seconds, you might expect 4 to take 120 seconds, but in really takes 105 unpatched or 80 patched. So we're not actually I/O constrained on this test, I think, perhaps because this machine has an SSD. -- 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
