On 2020-Aug-14, Ibrar Ahmed wrote: > The table used for the test contains three columns (integer, text, > varchar). > The total number of rows is 10000000 in total. > > Unpatched (Master: 92c12e46d5f1e25fc85608a6d6a19b8f5ea02600) > COPY: 9069.432 ms vacuum; 2567.961ms > COPY: 9004.533 ms vacuum: 2553.075ms > COPY: 8832.422 ms vacuum: 2540.742ms > > Patched (Master: 92c12e46d5f1e25fc85608a6d6a19b8f5ea02600) > COPY: 10031.723 ms vacuum: 127.524 ms > COPY: 9985.109 ms vacuum: 39.953 ms > COPY: 9283.373 ms vacuum: 37.137 ms > > Time to take the copy slightly increased but the vacuum time significantly > decrease.
"Slightly"? It seems quite a large performance drop to me -- more than 10%. Where is that time being spent? Andres said in [1] that he thought the performance shouldn't be affected noticeably, but this doesn't seem to hold true. As I understand, the idea was that there would be little or no additional WAL records .. only flags in the existing record. So what is happening? [1] https://postgr.es/m/20190408010427.4l63qr7h2fjcy...@alap3.anarazel.de Also, when Andres posted this patch first, he said this was only for heap_multi_insert because it was a prototype. But I think we expect that the table_insert path (CIM_SINGLE mode in copy) should also receive that treatment. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
