From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: file cloning in pg_upgrade and CREATE DATABASE |
Date: | 2018-03-19 07:14:15 |
Message-ID: | 20180319071415.GB4633@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 19, 2018 at 04:06:36PM +0900, Michael Paquier wrote:
> Any backend-side callers of copy_file() would not benefit from
> copyfile() on OSX. Shouldn't all that handling be inside copy_file(),
> similarly to what your patch actually does for pg_upgrade? I think that
> you should also consider fcopyfile() instead of copyfile() as it works
> directly on the file descriptors and share the same error handling as
> the others.
Two other things I have noticed as well:
1) src/bin/pg_rewind/copy_fetch.c could benefit from similar speed-ups I
think when copying data from source to target using the local mode of
pg_rewind. This could really improve cases where new relations are
added after a promotion.
2) XLogFileCopy() uses a copy logic as well. For large segments things
could be improved, however we need to be careful about filling in the
end of segments with zeros.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-03-19 07:18:48 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Kyotaro HORIGUCHI | 2018-03-19 07:11:39 | Re: User defined data types in Logical Replication |