Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <bc9ca382-b98d-0446-f699-8c5de2307ca7@2ndquadrant.com>
 <63b71efe-71c3-5849-0780-6b5447f5c7b1@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <9a3df7ee-6bc1-2ba6-7253-134e5bb9a943@2ndquadrant.com>
Date: Thu, 22 Feb 2018 17:49:48 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <63b71efe-71c3-5849-0780-6b5447f5c7b1@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2/21/18 18:57, Tomas Vondra wrote:
> Nice improvement, of course. How does that affect performance on the
> cloned database? If I understand this correctly, it essentially enables
> CoW on the files, so what's the overhead on that? It'd be unfortunate to
> speed up CREATE DATABASE only to get degraded performance later.

I ran a little test (on APFS and XFS): Create a large (unlogged) table,
copy the database, then delete everything from the table in the copy.
That should need to CoW all the blocks.  It has about the same
performance with cloning, possibly slightly faster.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services