Re: [PATCH] Incremental backup: add backup profile to base backup

On Fri, Aug 22, 2014 at 12:00:19PM -0400, Robert Haas wrote:
> On Wed, Aug 20, 2014 at 7:33 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> > On Wed, Aug 20, 2014 at 8:24 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> On Mon, Aug 18, 2014 at 04:05:07PM +0300, Heikki Linnakangas wrote:
> >>> But more to the point, I thought the consensus was to use the
> >>> highest LSN of all the blocks in the file, no? That's essentially
> >>> free to calculate (if you have to read all the data anyway), and
> >>> isn't vulnerable to collisions.
> >>
> >> The highest-LSN approach allows you to read only the tail part of each
> >> 8k block. Assuming 512-byte storage sector sizes, you only have to read
> >> 1/8 of the file.
> >>
> >> Now, the problem is that you lose kernel prefetch, but maybe
> >> posix_fadvise() would fix that problem.
> >
> > Sequential read of 512-byte blocks or 8k blocks takes the same amount
> > of time in rotating media (if they're scheduled right). Maybe not in
> > SSD media.
> >
> > Not only, the kernel will read in 4k blocks, instead of 8k (at least in linux).
> >
> > So, the benefit is dubious.
>
> Agreed. But, there could be a CPU benefit, too. Pulling the LSN out
> of a block is probably a lot cheaper than checksumming the whole
> thing.

Oh, good, I hoped someone would find something useful about my idea. :-)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +