Re: [HACKERS] Proposal: generic WAL compression - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Proposal: generic WAL compression
Date
Msg-id 20180207184254.GR2416@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Proposal: generic WAL compression  (Markus Nullmeier <dq124@uni-heidelberg.de>)
Responses Re: [HACKERS] Proposal: generic WAL compression  (Markus Nullmeier <dq124@uni-heidelberg.de>)
List pgsql-hackers
Greetings,

* Markus Nullmeier (dq124@uni-heidelberg.de) wrote:
> On 07/02/18 18:31, David Steele wrote:
>
> > This proposal is still in need of review and hasn't really gotten it in
> > the last few CFs.
>
> Agreed.
>
> > Since the feature does not seem like a good fit for the last CF of PG11
> > I am marking it Returned with Feedback.
>
> Is there any chance that it may be still resubmitted / reopened for the
> March CF?

Of course, you're certainly welcome to resubmit it to a future CF.  As
we're getting close to the end of this release cycle, I tend to think it
would be appropriate to submit it for the post-11 CF rather than the one
in March.

> Actually right now I am in the process of reviewing it, for it would be
> really useful for my "OUZO" project (a fork of the RUM access method).

Glad to hear that you're continuing to work on it.

> One general comment I can already make is that enabling compression
> should be made optional, which appears to be a small and easy addition
> to the generic WAL API.

The question would be- is there a way for us to determine when it should
be enabled or not enabled, or do we have to ask the user to tell us?
Asking the user is something we'd really not do unless we absolutely
have to.  Much better is if we can figure out when it's best to enable
or disable (or use/not use) based on some criteria and do so
automatically.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] [POC] Faster processing at Gather node
Next
From: Pierre Ducroquet
Date:
Subject: Re: JIT compiling with LLVM v10.0