public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 08/10] Default to zstd.. 2+ messages / 2 participants [nested] [flat]
* [PATCH 08/10] Default to zstd.. @ 2021-03-12 21:35 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ 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 20c6e08c02..dffe70208b 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 c4956745ce..780c0e785f 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 9bac79b579..5a8447a525 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 --0qVF/w3MHQqLSynd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0009-Add-zstd-compression-levels.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: using memoize in in paralel query decreases performance @ 2023-03-07 08:08 Pavel Stehule <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Pavel Stehule @ 2023-03-07 08:08 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> po 6. 3. 2023 v 22:52 odesÃlatel David Rowley <[email protected]> napsal: > On Mon, 6 Mar 2023 at 21:55, Pavel Stehule <[email protected]> > wrote: > > default https://explain.depesz.com/s/fnBe > > It looks like the slowness is coming from the Bitmap Index scan and > Bitmap heap scan rather than Memoize. > > -> Bitmap Heap Scan on public.item i (cost=285.69..41952.12 > rows=29021 width=16) (actual time=20.395..591.606 rows=20471 > loops=784) > Output: i.id, i.item_category_id > Recheck Cond: (i.item_category_id = ictc.sub_category_id) > Heap Blocks: exact=1590348 > Worker 0: actual time=20.128..591.426 rows=20471 loops=112 > Worker 1: actual time=20.243..591.627 rows=20471 loops=112 > Worker 2: actual time=20.318..591.660 rows=20471 loops=112 > Worker 3: actual time=21.180..591.644 rows=20471 loops=112 > Worker 4: actual time=20.226..591.357 rows=20471 loops=112 > Worker 5: actual time=20.597..591.418 rows=20471 loops=112 > -> Bitmap Index Scan on ixfk_ite_itemcategoryid > (cost=0.00..278.43 rows=29021 width=0) (actual time=14.851..14.851 > rows=25362 loops=784) > Index Cond: (i.item_category_id = ictc.sub_category_id) > Worker 0: actual time=14.863..14.863 rows=25362 loops=112 > Worker 1: actual time=14.854..14.854 rows=25362 loops=112 > Worker 2: actual time=14.611..14.611 rows=25362 loops=112 > Worker 3: actual time=15.245..15.245 rows=25362 loops=112 > Worker 4: actual time=14.909..14.909 rows=25362 loops=112 > Worker 5: actual time=14.841..14.841 rows=25362 loops=112 > > > disabled memoize https://explain.depesz.com/s/P2rP > > -> Bitmap Heap Scan on public.item i (cost=285.69..41952.12 > rows=29021 width=16) (actual time=9.256..57.503 rows=20471 loops=784) > Output: i.id, i.item_category_id > Recheck Cond: (i.item_category_id = ictc.sub_category_id) > Heap Blocks: exact=1590349 > Worker 0: actual time=9.422..58.420 rows=20471 loops=112 > Worker 1: actual time=9.449..57.539 rows=20471 loops=112 > Worker 2: actual time=9.751..58.129 rows=20471 loops=112 > Worker 3: actual time=9.620..57.484 rows=20471 loops=112 > Worker 4: actual time=8.940..57.911 rows=20471 loops=112 > Worker 5: actual time=9.454..57.488 rows=20471 loops=112 > -> Bitmap Index Scan on ixfk_ite_itemcategoryid > (cost=0.00..278.43 rows=29021 width=0) (actual time=4.581..4.581 > rows=25363 loops=784) > Index Cond: (i.item_category_id = ictc.sub_category_id) > Worker 0: actual time=4.846..4.846 rows=25363 loops=112 > Worker 1: actual time=4.734..4.734 rows=25363 loops=112 > Worker 2: actual time=4.803..4.803 rows=25363 loops=112 > Worker 3: actual time=4.959..4.959 rows=25363 loops=112 > Worker 4: actual time=4.402..4.402 rows=25363 loops=112 > Worker 5: actual time=4.778..4.778 rows=25363 loops=112 > > I wonder if the additional work_mem required for Memoize is just doing > something like causing kernel page cache evictions and leading to > fewer buffers for ixfk_ite_itemcategoryid and the item table being > cached in the kernel page cache. > > Maybe you could get an idea of that if you SET track_io_timing = on; > and EXPLAIN (ANALYZE, BUFFERS) both queries. > https://explain.depesz.com/s/vhk0 https://explain.depesz.com/s/R5ju Regards Pavel > David > ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-03-07 08:08 UTC | newest] Thread overview: 2+ 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-03-07 08:08 Re: using memoize in in paralel query decreases performance Pavel Stehule <[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