From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tackling full page writes |
Date: | 2011-05-26 00:12:52 |
Message-ID: | BANLkTikrKqAHcrbq1o23BuF-AcVq0-29xA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 24, 2011 at 1:34 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 1. Heikki suggested that instead of doing full page writes, we might
> try to write only the parts of the page that have changed. For
> example, if we had 16 bits to play with in the page header (which we
> don't), then we could imagine the page as being broken up into 16
> 512-byte chunks, one per bit. Each time we update the page, we write
> whatever subset of the 512-byte chunks we're actually modifying,
>
Alternately we could have change vectors which are something like
<offset,length,bytes[]> which I think would be a lot less wasteful than
dumping 512 byte chunks. The main advantage of 512 byte chunks is it's
easier to figure how what chunks to include in the output and if
you're replacing the entire block it looks just like our existing
system including not having to read in the page before writing. If we
output change vectors then we need to do some arithmetic to figure out
when it makes sense to merge records and how much of the block we need
to be replacing before we just decide to include the whole block.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Nolan | 2011-05-26 00:37:03 | Re: New/Revised TODO? Gathering actual read performance data for use by planner |
Previous Message | Robert Haas | 2011-05-25 23:29:55 | Re: pg_upgrade automatic testing |