On 2013-10-24 13:51:52 -0700, Josh Berkus wrote:
> On 10/24/2013 01:14 PM, Heikki Linnakangas wrote:
> > One extra WAL record whenever a hint bit is set on a page, for the first
> > time after a checkpoint. In other words, a WAL record needs to be
> > written in the same circumstances as with page checksums, but the WAL
> > records are much smaller as they don't need to contain a full page
> > image, just the block number of the changed block.
> > 
> > Or maybe we'll write the full page image after all, like with page
> > checksums, just without calculating the checksums. It might be tricky to
> > skip the full-page image, because then a subsequent change of the page
> > (which isn't just a hint-bit update) needs to somehow know it needs to
> > take a full page image even though a WAL record for it was already written.
> 
> I think it would be worth estimating what this actually looks like in
> terms of log write quantity.  My inclication is to say that if it
> increases log writes less than 10%, we don't need to provide an option
> to turn it off.

It entirely depends on your workload. If it happens to be something
like:
INSERT INTO table (lots_of_data);
CHECKPOINT;
SELECT * FROM TABLE;

i.e. there's a checkpoint between loading the data and reading it - not
exactly all that uncommon - we'll need to log something for every
page. That can be rather noticeable. Especially as I think it will be
rather hard to log anything but a real FPI.

I really don't think everyone will want this. I am absolutely not
against providing an option to log enough information to make pg_rewind
work, but I think providing a command to do *safe* *planned* failover
will help in many more.

Greetings,

Andres Freund

-- 
 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to