Re: [PATCH] Incremental backup: add backup profile to base backup
От | Bruce Momjian |
---|---|
Тема | Re: [PATCH] Incremental backup: add backup profile to base backup |
Дата | |
Msg-id | 20140822191515.GD21456@momjian.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Incremental backup: add backup profile to base backup (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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@gmail.com> wrote: > > On Wed, Aug 20, 2014 at 8:24 PM, Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: