From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: Online enabling of checksums |
Date: | 2018-02-24 02:11:36 |
Message-ID: | 20180224021136.cjceftzysmmiy7ec@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote:
> I agree having to restart the whole operation after a crash is not
> ideal, but I don't see how adding a flag actually solves it. The problem
> is the large databases often store most of the data (>80%) in one or two
> central tables (think fact tables in star schema, etc.). So if you
> crash, it's likely half-way while processing this table, so the whole
> table would still have relchecksums=false and would have to be processed
> from scratch.
I don't think it's quite as large a problem as you make it out to
be. Even in those cases you'll usually have indexes, toast tables and so
forth.
> But perhaps you meant something like "position" instead of just a simple
> true/false flag?
I think that'd incur a much larger complexity cost.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-02-24 02:15:28 | Re: Translations contributions urgently needed |
Previous Message | Tomas Vondra | 2018-02-24 02:07:28 | Re: Online enabling of checksums |