public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH 08/10] Default to zstd..
3+ messages / 3 participants
[nested] [flat]

* [PATCH 08/10] Default to zstd..
@ 2021-03-12 21:35  Justin Pryzby <[email protected]>
  0 siblings, 0 replies; 3+ messages in thread

From: Justin Pryzby @ 2021-03-12 21:35 UTC (permalink / raw)

for CI, not for merge
---
 configure                         | 6 ++++--
 configure.ac                      | 2 +-
 src/backend/access/transam/xlog.c | 2 +-
 src/backend/utils/misc/guc.c      | 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 81e23418b2..253f028fc4 100755
--- a/configure
+++ b/configure
@@ -1582,7 +1582,7 @@ Optional Packages:
                           use system time zone data in DIR
   --without-zlib          do not use Zlib
   --without-lz4           build without LZ4 support
-  --with-zstd             build with Zstd compression library
+  --without-zstd          build without Zstd compression library
   --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
   --with-ssl=LIB          use LIB for SSL/TLS support (openssl)
   --with-openssl          obsolete spelling of --with-ssl=openssl
@@ -8740,7 +8740,9 @@ $as_echo "#define USE_ZSTD 1" >>confdefs.h
   esac
 
 else
-  with_zstd=no
+  with_zstd=yes
+
+$as_echo "#define USE_ZSTD 1" >>confdefs.h
 
 fi
 
diff --git a/configure.ac b/configure.ac
index d6f6349067..8d72710fa7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1005,7 +1005,7 @@ fi
 # ZSTD
 #
 AC_MSG_CHECKING([whether to build with zstd support])
-PGAC_ARG_BOOL(with, zstd, no, [build with Zstd compression library],
+PGAC_ARG_BOOL(with, zstd, yes, [build without Zstd compression library],
               [AC_DEFINE([USE_ZSTD], 1, [Define to 1 to build with zstd support. (--with-zstd)])])
 AC_MSG_RESULT([$with_zstd])
 AC_SUBST(with_zstd)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 307eee6626..92023de9f5 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -99,7 +99,7 @@ bool		EnableHotStandby = false;
 bool		fullPageWrites = true;
 bool		wal_log_hints = false;
 bool		wal_compression = false;
-int			wal_compression_method = WAL_COMPRESSION_LZ4;
+int			wal_compression_method = WAL_COMPRESSION_ZSTD;
 char	   *wal_consistency_checking_string = NULL;
 bool	   *wal_consistency_checking = NULL;
 bool		wal_init_zero = true;
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 52f9cd0242..8031e027aa 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4728,7 +4728,7 @@ static struct config_enum ConfigureNamesEnum[] =
 			NULL
 		},
 		&wal_compression_method,
-		WAL_COMPRESSION_LZ4, wal_compression_options,
+		WAL_COMPRESSION_ZSTD, wal_compression_options,
 		NULL, NULL, NULL
 	},
 
-- 
2.17.0


--XsQoSWH+UP9D9v3l
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0009-Add-zstd-compression-levels.patch"



^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* pgbench with libevent?
@ 2023-08-13 09:32  Fabien COELHO <[email protected]>
  0 siblings, 1 reply; 3+ messages in thread

From: Fabien COELHO @ 2023-08-13 09:32 UTC (permalink / raw)
  To: PostgreSQL Developers <[email protected]>


Hello devs,

Pgbench is managing clients I/Os manually with select or poll. Much of 
this could be managed by libevent.

Pros:

1. libevent is portable, stable, and widely used (eg Chromium, Memcached, PgBouncer).

2. libevent implements more I/O wait methods, which may be more efficient on some platforms
    (eg FreeBSD kqueue, Windows wepoll in libevent 2.2 alpha), and hides portability issues.

3. it would remove significant portions of unattractive pgbench code, esp. in threadRun,
    and around socket/poll abstraction and portability layer.

4. depending on the number of event loops, the client load could be shared more evenly.
    currently a thread only manages its own clients, some client I/Os may be waiting to be
    processed while other threads could be available to process them.

Cons:

1. it adds a libevent dependency to postgres. This may be a no go from the start.

2. this is a significant refactoring project which implies a new internal architecture and adds
    new code to process and generate appropriate events.

3. libevent ability to function efficiently in a highly multithreaded environment
    is unclear. Should there be one event queue which generate a shared work queue?
    or several event queues, one per thread (which would remove the sharing pro)?
    or something in between? Some experiments and configuratibility may be desirable.
    This may also have an impact on pgbench user interface and output depending on the result,
    eg there may be specialized event and worker threads, some statistics may be slightly
    different, new options may be needed…

4. libevent development seems slugish, last bugfix was published 3 years ago, version
    2.2 has been baking for years, but the development seems lively (+100 contributors).

Neutral?

1. BSD 3 clauses license.

Is pros > cons, or not? Other thoughts, pros, cons?

-- 
Fabien.

^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: pgbench with libevent?
@ 2023-08-14 09:38  Alvaro Herrera <[email protected]>
  parent: Fabien COELHO <[email protected]>
  0 siblings, 0 replies; 3+ messages in thread

From: Alvaro Herrera @ 2023-08-14 09:38 UTC (permalink / raw)
  To: Fabien COELHO <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>

On 2023-Aug-13, Fabien COELHO wrote:

> 4. libevent development seems slugish, last bugfix was published 3 years ago, version
>    2.2 has been baking for years, but the development seems lively (+100 contributors).

Ugh, I would stay away from something like that.  Would we become
hostage to an undelivering group?  No thanks.

On 2023-Aug-14, Fabien COELHO wrote:

> Or maybe libuv (used by nodejs?).

> Note: libev had no updates in 8 years.

libev or libuv?  No updates in 8 years => dead.  No way.


Reworking based on wait events as proposed downthread sounds more
promising.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual)






^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2023-08-14 09:38 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-12 21:35 [PATCH 08/10] Default to zstd.. Justin Pryzby <[email protected]>
2023-08-13 09:32 pgbench with libevent? Fabien COELHO <[email protected]>
2023-08-14 09:38 ` Re: pgbench with libevent? Alvaro Herrera <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox