Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

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.4l63qr7h2fjcyp77@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