From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Junji TERAMOTO <teramoto(dot)junji(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Quick-and-dirty compression for WAL backup blocks |
Date: | 2005-06-06 16:13:19 |
Message-ID: | Pine.OSF.4.61.0506061855001.90010@kosh.hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 6 Jun 2005, Tom Lane wrote:
> Junji TERAMOTO <teramoto(dot)junji(at)lab(dot)ntt(dot)co(dot)jp> writes:
>
>> In "whole buffer log", there is a page header that includes offset of
>> "hole" (lower and upper). If we use that information, we don't need
>> any overhead, do we?
>
> No, because the WAL code cannot assume that all pages follow the
> convention that pd_lower and pd_upper represent the boundaries of
> free space. (As a counterexample: index metapages don't always
> do that.) I think the transformation has to be guaranteed lossless,
> which means that at a minimum you'd need to check whether the data
> in between pd_lower and pd_upper really is zeroes. So the irreducible
> minimum overhead is 1 bit to tell whether you compressed or not.
Vacuum doesn't zero out the free space between lower and upper, it's
just marked as unused, so a lossless compression becomes less efficient
on tables that have free space released by vacuum in them.
How about adding a flag to XLogRecData to indicate if the space between
pd_lower and pd_upper is meaningful or not? The XLogInsert caller probably
knows that. That way you could completely skip over the free space if
it's not meaningful, saving even more cycles.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-06 16:24:45 | Re: Quick-and-dirty compression for WAL backup blocks |
Previous Message | Markus Bertheau ☭ | 2005-06-06 16:12:46 | Re: [SQL] ARRAY() returning NULL instead of ARRAY[] |