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
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
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
Phil Sorber wrote:
On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus j...@agliodbs.com 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
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
Jonathan Rogers jrog...@socialserve.com 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
Tom Lane wrote:
Jonathan Rogers jrog...@socialserve.com 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
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 we
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 could work
On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus j...@agliodbs.com 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
Jonathan Rogers jrog...@socialserve.com 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
11 matches
Mail list logo
