I wrote:
> That seems like the appropriate answer to me. I verified that we
> build cleanly and pass check-world against 1.4.0, and later I'm
> going to set up BF member longfin to use that.
Done ...
> In short, I think we should push Justin's version-check patch,
> and also fix the SGML docs
On Thu, Mar 31, 2022 at 09:10:00PM -0400, Tom Lane wrote:
> In short, I think we should push Justin's version-check patch,
> and also fix the SGML docs to say that we require zstd >= 1.4.0.
1.4.0 was released in April 2019, just 3 years ago. It does not sound
that bad to me to make this version
Robert Haas writes:
> On Thu, Mar 31, 2022 at 7:38 PM Tom Lane wrote:
>> Indeed. I tried building against 1.3.6 (mainly because it was laying
>> around) and the error reported by Devrim is just the tip of the iceberg.
>> ...
>> I wonder whether Robert's ambition to be compatible with old
On Thu, Mar 31, 2022 at 7:38 PM Tom Lane wrote:
> Indeed. I tried building against 1.3.6 (mainly because it was laying
> around) and the error reported by Devrim is just the tip of the iceberg.
> With "make -k", I see unknown-symbol failures on
>
> ZSTD_CCtx_setParameter
>
Justin Pryzby writes:
> On Thu, Mar 31, 2022 at 11:44:40AM -0400, Tom Lane wrote:
>> In view of 51c0d186d ("Allow parallel zstd compression"), I agree
>> that some clarity about the minimum supported version of zstd
>> seems essential. I don't want to be dealing with threading bugs
>> in ancient
On Thu, Mar 31, 2022 at 11:44:40AM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > Possible responses look like:
> > - Use 0 which also means "default" (need to verify that works across
> > versions);
> > - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> > - Add a test for
On Thu, Mar 31, 2022 at 12:37 PM Tom Lane wrote:
> Hm. After rereading 51c0d186d I see that we're not asking for
> parallel compression unless the user tells us to, so I guess
> our fallback answer for any complaints in that area can be
> "if it hurts, don't do it".
Right. We can also tell
Robert Haas writes:
> On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
>> In view of 51c0d186d ("Allow parallel zstd compression"), I agree
>> that some clarity about the minimum supported version of zstd
>> seems essential. I don't want to be dealing with threading bugs
>> in ancient zstd
On Thu, Mar 31, 2022 at 12:26:46PM -0400, Robert Haas wrote:
> On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
> > Justin Pryzby writes:
> > > Possible responses look like:
> > > - Use 0 which also means "default" (need to verify that works across
> > > versions);
> > > - Or #ifndef
On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
> Justin Pryzby writes:
> > Possible responses look like:
> > - Use 0 which also means "default" (need to verify that works across
> > versions);
> > - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> > - Add a test for a
Justin Pryzby writes:
> Possible responses look like:
> - Use 0 which also means "default" (need to verify that works across
> versions);
> - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> - Add a test for a minimum zstd version v1.3.7. This may be a good idea for
>v15
On Thu, Mar 31, 2022 at 03:38:39PM +0100, Devrim Gündüz wrote:
> On Thu, 2022-03-31 at 10:26 -0400, Tom Lane wrote:
> > Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> > > Latest snapshot tarball fails to build on SLES 12.5, which uses GCC
> > > 4.8-8. Build log is attached.
> >
> > Hmm, what
On Fri, Mar 11, 2022 at 03:49:00PM -0600, Justin Pryzby wrote:
> While rebasing, I realized this should have bumped XLOG_PAGE_MAGIC.
>
> Also, there's a dangling "and".
Right. I'll address that a bit later today. Thanks!
--
Michael
signature.asc
Description: PGP signature
While rebasing, I realized this should have bumped XLOG_PAGE_MAGIC.
Also, there's a dangling "and".
+The supported methods are pglz,
+lz4 (if PostgreSQL
+was compiled with --with-lz4) and
+zstd (if PostgreSQL
+was compiled with --with-zstd) and
+
On Fri, Mar 11, 2022 at 12:23:59PM +0900, Michael Paquier wrote:
> On Wed, Mar 09, 2022 at 07:14:11AM -0600, Justin Pryzby wrote:
> > Anyway there's no compelling reason to not use the default. If we were to
> > use
> > a non-default default, we'd have to choose between 1 and 2 (or some negative
On Wed, Mar 09, 2022 at 07:14:11AM -0600, Justin Pryzby wrote:
> Anyway there's no compelling reason to not use the default. If we were to use
> a non-default default, we'd have to choose between 1 and 2 (or some negative
> compression level). My thinking was that zstd-1 would give the
3 = 77% of the
> cost.
Actually, my test used zstd-6, rather than the correct default of 3.
The comparison should have been:
postgres=# SET wal_compression='zstd-1';
postgres=# \set QUIET \\ \timing on \\ SET max_parallel_maintenance_workers=0;
SELECT pg_stat_reset_shared('wal'); begin; CREATE I
hael
test.tar.gz
Description: application/gzip
pg_rusage.tar.gz
Description: application/gzip
From 254ddbf4223c35a7990e301e53d6ddbffcf210c0 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Fri, 18 Feb 2022 22:54:18 -0600
Subject: [PATCH v2] add wal_compression=zstd
---
src/inc
On Fri, Mar 04, 2022 at 08:10:35AM -0500, Andrew Dunstan wrote:
> I don't see why patch 5 shouldn't be applied forthwith.
Only applying 0005 would result in a failure in the TAP test for a
problem whose fix is attempted in 0006. This is an issue unrelated to
this thread.
FWIW, I am a bit
On Fri, Mar 04, 2022 at 08:08:03AM -0500, Robert Haas wrote:
> On Fri, Mar 4, 2022 at 6:44 AM Justin Pryzby wrote:
>> In my 1-off test, it gets 610/633 = 96% of the benefit at 209/273 = 77% of
>> the
>> cost.
Hmm, it may be good to start afresh and compile numbers in a single
chart. I did that
On 2/22/22 18:19, Justin Pryzby wrote:
> As writen, this patch uses zstd level=1 (whereas the ZSTD's default compress
> level is 6).
I think this choice needs to be supported by some benchmarks.
>
> 0001 adds support for zstd
> 0002 makes more efficient our use of bits in the WAL header
>
On Fri, Mar 4, 2022 at 6:44 AM Justin Pryzby wrote:
> > Why? ZSTD using this default has its reasons, no? And it would be
> > consistent to do the same for ZSTD as for the other two methods.
>
> In my 1-off test, it gets 610/633 = 96% of the benefit at 209/273 = 77% of the
> cost.
I agree with
default has its reasons, no? And it would be
> consistent to do the same for ZSTD as for the other two methods.
In my 1-off test, it gets 610/633 = 96% of the benefit at 209/273 = 77% of the
cost.
postgres=# SET wal_compression= 'zstd-6';
postgres=# \set QUIET \\ \timing on \\ SET max_parallel_mai
On Tue, Feb 22, 2022 at 05:19:48PM -0600, Justin Pryzby wrote:
> I am not claiming that zstd is generally better for WAL. Rather, if we're
> going to support alternate compression methods, it's nice to give a couple
> options (in addition to pglz). Some use cases would certainly suffer from
>
Since 4035cd5d4, wal_compression=lz4 is supported. I think pg15 should also
support wal_compression=zstd. There are free bits in the WAL header.
The last message on that thread includes a patch doing just that, which I've
rebased.
https://www.postgresql.org/message-id/ynqwd2gsmrnqw
25 matches
Mail list logo
