Re: COPY performance on Windows

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

In response to

Responses

Browse pgsql-hackers by date

  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)