Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Compression of full-page-writes
Date
Msg-id CAB7nPqTZP6Jfum+hNFAWBxXd23FMt3S8ytQTKH+r8booLNsY9g@mail.gmail.com
Whole thread Raw
In response to Re: Compression of full-page-writes  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Compression of full-page-writes  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Dec 8, 2014 at 11:30 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> * parameter should be SUSET - it doesn't *need* to be set only at
> server start since all records are independent of each other
Check.

> * ideally we'd like to be able to differentiate the types of usage.
> which then allows the user to control the level of compression
> depending upon the type of action. My first cut at what those settings
> should be are ALL > LOGICAL > PHYSICAL > VACUUM.
> VACUUM - only compress while running vacuum commands
> PHYSICAL - only compress while running physical DDL commands (ALTER
> TABLE set tablespace, CREATE INDEX), i.e. those that wouldn't
> typically be used for logical decoding
> LOGICAL - compress FPIs for record types that change tables
> ALL - all user commands
> (each level includes all prior levels)

Well, that's clearly an optimization so I don't think this should be
done for a first shot but those are interesting fresh ideas.
Technically speaking, note that we would need to support such things
with a new API to switch a new context flag in registered_buffers of
xloginsert.c for each block, and decide if the block is compressed
based on this context flag, and the compression level wanted.

> * name should not be wal_compression - we're not compressing all wal
> records, just fpis. There is no evidence that we even want to compress
> other record types, nor that our compression mechanism is effective at
> doing so. Simple => keep name as compress_full_page_writes
> Though perhaps we should have it called wal_compression_level

I don't really like those new names, but I'd prefer
wal_compression_level if we go down that road with 'none' as default
value. We may still decide in the future to support compression at the
record level instead of context level, particularly if we have an API
able to do palloc_return_null_at_oom, so the idea of WAL compression
is not related only to FPIs IMHO.
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: Testing DDL deparsing support
Next
From: Adam Brightwell
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation