| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Incremental backup: add backup profile to base backup |
| Date: | 2014-08-20 23:33:20 |
| Message-ID: | CAGTBQpZatSD0JZ-1D7V2cxeV-9cVQS6_Hx_ANdc+Lr+wOacMFg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-08-20 23:33:38 | Re: Proposal to add a QNX 6.5 port to PostgreSQL |
| Previous Message | Andres Freund | 2014-08-20 23:24:58 | Re: Proposal to add a QNX 6.5 port to PostgreSQL |