On 3/9/13 11:39 PM, Jonathan Rogers wrote:
In an earlier implementation, I did call "cp --reflink=auto" once per
regular file, preserving the behavior of copydir. On Btrfs, this works
well, though slightly slower due to extra processes. AFAIK, there's no
way to do something equivalent on ZFS with
Greg Smith wrote:
> I think I can see how to construct such an example for the btrfs
> version, but having you show that explicitly (preferably with a whole
> sample session executing it) will also help reviewers. Remember: if
> you want to get your submission off to a good start, the reviewer sh
On 3/1/13 1:40 AM, Jonathan Rogers wrote:
I've been thinking about both of these issues and decided to try a
different approach. This patch adds GUC options for two external
commands
This is a reasonable approach for a proof of concept patch. I like the
idea you're playing with here, as a use
Phil Sorber wrote:
> On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus wrote:
>> On 02/13/2013 02:13 PM, Tom Lane wrote:
>>> The big-picture question of course is whether we want to carry and
>>> maintain a filesystem-specific hack. I don't have a sense that btrfs
>>> is so widely used as to justify t
Jonathan Rogers writes:
> Would it be better to move clone_file() into its own module where
> implementations for other file system types might eventually be added?
Yeah, possibly. I considered suggesting that the current code be
treated as a fallback implementation of clone_file, but I'm not su
On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus wrote:
> On 02/13/2013 02:13 PM, Tom Lane wrote:
>> The big-picture question of course is whether we want to carry and
>> maintain a filesystem-specific hack. I don't have a sense that btrfs
>> is so widely used as to justify this.
>
> If this is a val
Josh Berkus wrote:
> On 02/13/2013 02:13 PM, Tom Lane wrote:
>> The big-picture question of course is whether we want to carry and
>> maintain a filesystem-specific hack. I don't have a sense that btrfs
>> is so widely used as to justify this.
>
> If this is a valuable hack, it seems like it coul
On 02/13/2013 02:13 PM, Tom Lane wrote:
> The big-picture question of course is whether we want to carry and
> maintain a filesystem-specific hack. I don't have a sense that btrfs
> is so widely used as to justify this.
If this is a valuable hack, it seems like it could work on ZFS as well.
If w
Tom Lane wrote:
> Jonathan Rogers writes:
>> This patch against PostgreSQL 9.1.8 takes advantage of efficient file
>> cloning on Linux Btrfs file systems to make CREATE DATABASE operations
>> extremely fast regardless of the size of the database used as a
>> template.
>
> It would be easier to re
Jonathan Rogers writes:
> This patch against PostgreSQL 9.1.8 takes advantage of efficient file
> cloning on Linux Btrfs file systems to make CREATE DATABASE operations
> extremely fast regardless of the size of the database used as a
> template.
It would be easier to review this patch if the bul
This patch against PostgreSQL 9.1.8 takes advantage of efficient file
cloning on Linux Btrfs file systems to make CREATE DATABASE operations
extremely fast regardless of the size of the database used as a
template. On my system, I can create a database from a multi-gibibyte
template in a second or
11 matches
Mail list logo
