| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [RFC] LSN Map |
| Date: | 2015-01-07 15:16:19 |
| Message-ID: | 20150107151619.GG17824@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 7, 2015 at 10:50:38AM +0100, Marco Nenciarini wrote:
> Implementation
> --------------
>
> We create an additional fork which contains a raw stream of LSNs. To
> limit the space used, every entry represent the maximum LSN of a group
> of blocks of a fixed size. I chose arbitrarily the size of 2048
> which is equivalent to 16MB of heap data, which means that we need 64k
> entry to track one terabyte of heap.
I like the idea of summarizing the LSN to keep its size reaonable. Have
you done any measurements to determine how much backup can be skipped
using this method for a typical workload, i.e. how many 16MB page ranges
are not modified in a typical span between incremental backups?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-01-07 15:33:20 | Re: [RFC] LSN Map |
| Previous Message | Kevin Grittner | 2015-01-07 15:14:05 | Re: Turning recovery.conf into GUCs |