Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Date
Msg-id 594C9457.6000708@anastigmatix.net
Whole thread Raw
In response to Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
List pgsql-hackers
On 06/21/17 04:51, Heikki Linnakangas wrote:
> (I'm cleaning up my inbox, hence the delayed reply)

I had almost completely forgotten ever bringing it up. :)

> When I wrote that code, I don't remember if I realized that we're
> initializing the page headers, or if I thought that it's good enough even if
> we do. I guess I didn't realize it, because a comment would've been in order
> if it was intentional.
> 
> So +1 on fixing that, a patch would be welcome.

Ok, that sounds like something I could take a whack at. Overall, xlog.c
is a bit daunting, but this particular detail seems fairly approachable.

> In the meanwhile, have you
> tried using a different compression program? Something else than gzip might
> do a better job at the almost zero pages.

Well, gzip was doing pretty well; it could get a 16 MB segment file down
to under 27 kB, or less than 14 bytes for each of 2000 pages, when a page
header is what, 20 bytes, it looks like? I'm not sure how much better
I'd expect a (non-custom) compression scheme to do. The real difference
comes between compressing (even well) a large unchanged area, versus being
able to recognize (again with a non-custom tool) that the whole area is
unchanged.

-Chap



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] Missing comment for create_modifytable_path
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests