| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [RFC] LSN Map |
| Date: | 2015-01-07 15:46:04 |
| Message-ID: | 20150107154604.GH17824@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 7, 2015 at 12:33:20PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > 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?
>
> That seems entirely dependent on the specific workload.
Well, obviously. Is that worth even stating?
My question is whether there are enough workloads for this to be
generally useful, particularly considering the recording granularity,
hint bits, and freezing. Do we have cases where 16MB granularity helps
compared to file or table-level granularity? How would we even measure
the benefits? How would the administrator know they are benefitting
from incremental backups vs complete backups, considering the complexity
of incremental restores?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-01-07 16:01:52 | Re: INSERT ... ON CONFLICT UPDATE and RLS |
| Previous Message | Tom Lane | 2015-01-07 15:41:43 | Re: [RFC] LSN Map |