On 05/11/2026 06:27, Chao Li wrote:
Although not needed anymore, attached is the simple benchmark COPY FROM on 4 millions rows for info:I have an extra worry about performance regressions, previously from [1], i saw that very minimal changes effect the binary layout and branching (without going into much details), therefore having 1-3% performance regressions or improvements that appear just like that (this applies everywhere in Postgres really...), CopyReadAttributesCSV() is very sensitive, it runs millions of times very easily and its a high registers-pressured code.A not too serious benchmark on v2 already shows 5% regressions.Could you share how you ran the benchmark and measured the 5% regression? I ran a brief benchmark with assertions disabled and -O2. The test copies 1 million rows into a table with 32 text columns. The results are: ``` | Version | Format | Runs | Average time | Change vs master | |---|---|---:|---:|---:| | Master (`590788ad0bf`) | CSV | 6 | 625.382 ms | — | | Master | Text | 5 | 627.275 ms | — | | Master | Binary | 5 | 795.974 ms | — | | v2 | CSV | 5 | 641.186 ms | +2.53% | | v2 | Text | 5 | 607.293 ms | −3.19% | | v2 | Binary | 6 | 785.810 ms | −1.28% | ```
I run these too: (On my laptop with an Intel I7-1255U CPU) sudo cpupower frequency-set --governor=performance sudo cpupower idle-set -D 0 echo "1" | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo pinned backend to a performance core non-assert, -O2 build Latest time i ran this i got 2.5%-3% regression.
The attached v3 restores the v1 fix. I only adjusted the commit message formatting and added author/reviewer annotations.
Looks good, thanks. Regards, Ayoub Kazar
bench_copy.sql
Description: application/sql
