public inbox for [email protected]help / color / mirror / Atom feed
[PATCH] Disable background workers during servers start in pg_upgrade 25+ messages / 3 participants [nested] [flat]
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* [PATCH] Disable background workers during servers start in pg_upgrade @ 2021-01-20 16:25 Denis Laxalde <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Denis Laxalde @ 2021-01-20 16:25 UTC (permalink / raw) We disable shared_preload_libraries to prevent background workers to initialize and start during server start in pg_upgrade. In essence, this is for a similar reason that we use a restricted socket access from f763b77193b04eba03a1f4ce46df34dc0348419e because background workers may produce undesired activities during the upgrade. Author: Denis Laxalde <[email protected]> Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]> --- src/bin/pg_upgrade/server.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/bin/pg_upgrade/server.c b/src/bin/pg_upgrade/server.c index 31b1425202..fab95a2d24 100644 --- a/src/bin/pg_upgrade/server.c +++ b/src/bin/pg_upgrade/server.c @@ -240,11 +240,13 @@ start_postmaster(ClusterInfo *cluster, bool report_and_exit_on_error) * crash, the new cluster has to be recreated anyway. fsync=off is a big * win on ext4. * + * Turn off background workers by emptying shared_preload_libraries. + * * Force vacuum_defer_cleanup_age to 0 on the new cluster, so that * vacuumdb --freeze actually freezes the tuples. */ snprintf(cmd, sizeof(cmd), - "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start", + "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s -c shared_preload_libraries=''\" start", cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? " -b" : -- 2.20.1 --lvvxlk2k67d5kdun-- ^ permalink raw reply [nested|flat] 25+ messages in thread
* Performance of JSON_TABLE vs jsonb_to_recordset @ 2024-04-20 11:00 Alexander Lakhin <[email protected]> 0 siblings, 2 replies; 25+ messages in thread From: Alexander Lakhin @ 2024-04-20 11:00 UTC (permalink / raw) To: pgsql-hackers Hello hackers, When playing with JSON_TABLE, I tried to replace tenk1 in regression tests with a view based on JSON_TABLE, with the same content, and discovered that for one sub-optimal query it's execution duration increased many-fold. With the preparation script attached, I see the following durations (for a build compiled by clang 18.1.3 with -O3): explain (verbose, analyze) select (select max((select i.unique2 from tenk1 i where i.unique1 = o.unique1))) from tenk1 o; -- original tenk1 Execution Time: 4769.481 ms explain (verbose, analyze) select (select max((select i.unique2 from jsonb_rs_tenk1 i where i.unique1 = o.unique1))) from jsonb_rs_tenk1 o; -- Function Call: jsonb_to_recordset... Execution Time: 6841.767 ms explain (verbose, analyze) select (select max((select i.unique2 from jsontable_tenk1 i where i.unique1 = o.unique1))) from jsontable_tenk1 o; -- Table Function Call: JSON_TABLE... Execution Time: 288310.131 ms (with 63% of time spent inside ExecEvalJsonExprPath()) Just for fun I've tested also XMLTABLE with the similar content: explain (verbose, analyze) select (select max((select i.unique2 from xml_tenk1 i where i.unique1 = o.unique1))) from xml_tenk1 o; -- Table Function Call: XMLTABLE... Execution Time: 1235066.636 ms Maybe it's worth to add a note to the JSON_TABLE() documentation saying that jsonb_to_recordset is (inherently?) more performant when processing arrays of flat structures for users not to re-discover this fact... Best regards, Alexander Attachments: [application/sql] jsontable-perf-setup.sql (2.6K, ../../[email protected]/2-jsontable-perf-setup.sql) download ^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Performance of JSON_TABLE vs jsonb_to_recordset @ 2024-04-20 14:47 Tom Lane <[email protected]> parent: Alexander Lakhin <[email protected]> 1 sibling, 1 reply; 25+ messages in thread From: Tom Lane @ 2024-04-20 14:47 UTC (permalink / raw) To: Alexander Lakhin <[email protected]>; +Cc: pgsql-hackers Alexander Lakhin <[email protected]> writes: > When playing with JSON_TABLE, I tried to replace tenk1 in regression tests > with a view based on JSON_TABLE, with the same content, and discovered > that for one sub-optimal query it's execution duration increased many-fold. > With the preparation script attached, I see the following durations > (for a build compiled by clang 18.1.3 with -O3): > explain (verbose, analyze) > select > (select max((select i.unique2 from tenk1 i where i.unique1 = o.unique1))) > from tenk1 o; > -- original tenk1 > Execution Time: 4769.481 ms Hm, I get about 13 ms for that example. Do you have some really expensive debugging infrastructure enabled, perhaps? regards, tom lane ^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Performance of JSON_TABLE vs jsonb_to_recordset @ 2024-04-20 14:58 Tom Lane <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 25+ messages in thread From: Tom Lane @ 2024-04-20 14:58 UTC (permalink / raw) To: Alexander Lakhin <[email protected]>; +Cc: pgsql-hackers I wrote: > Alexander Lakhin <[email protected]> writes: >> explain (verbose, analyze) >> select >> (select max((select i.unique2 from tenk1 i where i.unique1 = o.unique1))) >> from tenk1 o; >> -- original tenk1 >> Execution Time: 4769.481 ms > Hm, I get about 13 ms for that example. Do you have some really > expensive debugging infrastructure enabled, perhaps? Oh, never mind, now I see you are testing a version of the table with no indexes, rather than the way it's set up in the regression database. Apologies for the noise. regards, tom lane ^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: Performance of JSON_TABLE vs jsonb_to_recordset @ 2024-04-20 17:12 Tom Lane <[email protected]> parent: Alexander Lakhin <[email protected]> 1 sibling, 0 replies; 25+ messages in thread From: Tom Lane @ 2024-04-20 17:12 UTC (permalink / raw) To: Alexander Lakhin <[email protected]>; +Cc: pgsql-hackers Alexander Lakhin <[email protected]> writes: > explain (verbose, analyze) > select > (select max((select i.unique2 from jsontable_tenk1 i where i.unique1 = o.unique1))) > from jsontable_tenk1 o; > -- Table Function Call: JSON_TABLE... > Execution Time: 288310.131 ms > (with 63% of time spent inside ExecEvalJsonExprPath()) Yeah, I looked at this with perf too, and what I'm seeing is - 55.87% ExecEvalJsonExprPath - 39.30% JsonPathValue - 37.63% executeJsonPath - 34.87% executeItem (inlined) - executeItemOptUnwrapTarget - 32.39% executeNextItem - 31.02% executeItem (inlined) - 30.90% executeItemOptUnwrapTarget - 26.81% getKeyJsonValueFromContainer 14.35% getJsonbOffset (inlined) - 4.90% lengthCompareJsonbString (inlined) 3.19% __memcmp_avx2_movbe - 2.32% palloc 1.67% AllocSetAlloc 0.93% fillJsonbValue 1.18% executeNextItem 0.51% findJsonbValueFromContainer - 1.04% jspGetNext 0.72% jspInitByBuffer - 1.46% check_stack_depth stack_is_too_deep (inlined) 0.61% jspInitByBuffer - 9.82% ExecGetJsonValueItemString (inlined) - 8.68% DirectFunctionCall1Coll - 8.07% numeric_out - 6.15% get_str_from_var - 2.07% palloc - 1.80% AllocSetAlloc 0.72% AllocSetAllocChunkFromBlock (inlined) 1.28% init_var_from_num - 1.61% namein 0.90% __strlen_avx2 0.52% palloc0 - 0.74% int4in 0.69% pg_strtoint32_safe Depressingly small amount of useful work being done there compared to the management overhead. Seems like some micro-optimization in this area could be a useful project for v18. regards, tom lane ^ permalink raw reply [nested|flat] 25+ messages in thread
end of thread, other threads:[~2024-04-20 17:12 UTC | newest] Thread overview: 25+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2021-01-20 16:25 [PATCH] Disable background workers during servers start in pg_upgrade Denis Laxalde <[email protected]> 2024-04-20 11:00 Performance of JSON_TABLE vs jsonb_to_recordset Alexander Lakhin <[email protected]> 2024-04-20 14:47 ` Re: Performance of JSON_TABLE vs jsonb_to_recordset Tom Lane <[email protected]> 2024-04-20 14:58 ` Re: Performance of JSON_TABLE vs jsonb_to_recordset Tom Lane <[email protected]> 2024-04-20 17:12 ` Re: Performance of JSON_TABLE vs jsonb_to_recordset Tom Lane <[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