From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Ryohei Takahashi (Fujitsu)" <r(dot)takahashi_2(at)fujitsu(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: COPY performance on Windows |
Date: | 2024-11-05 15:45:55 |
Message-ID: | CA+TgmoZ=z8rymWXV-DZMaZ8jqsY+uUBKF=0TNuPDL+dCJMW7KA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Takahashi-san,
I am reluctant to draw conclusions about the general performance of
this patch from one example. It seems that the performance could
depend on many things: table size, column definitions, row width,
hardware, OS version, shared_buffers, max_wal_size. I don't think we
can say from your test here that performance is always worse on
Windows. If it is, then I agree that we should think of what to do
about it; but it seems possible to me that the behavior will be
different in other circumstances.
What I don't understand is why increasing the number of blocks should
be worse. The comment before the FileZero() call has a comment
explaining why a larger extension is thought to be better. If it's
wrong, we should try to figure out why it's wrong. But it seems quite
surprising that doing more work at once would be less efficient.
That's not usually how things work.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-11-05 15:55:12 | Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch) |
Previous Message | Ashutosh Bapat | 2024-11-05 15:41:24 | Re: SQL Property Graph Queries (SQL/PGQ) |