public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/4] demote: setter functions for LocalXLogInsert local variable 3+ messages / 2 participants [nested] [flat]
* [PATCH 1/4] demote: setter functions for LocalXLogInsert local variable @ 2020-07-31 08:58 Jehan-Guillaume de Rorthais <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Jehan-Guillaume de Rorthais @ 2020-07-31 08:58 UTC (permalink / raw) Adds functions extern LocalSetXLogInsertNotAllowed() and LocalSetXLogInsertCheckRecovery() to set the local variable LocalXLogInsert respectively to 0 and -1. These functions are declared as extern for future need in the demote patch. Function LocalSetXLogInsertAllowed() already exists and declared as static as it is not needed outside of xlog.h. --- src/backend/access/transam/xlog.c | 27 +++++++++++++++++++++++---- src/include/access/xlog.h | 2 ++ 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 09c01ed4ae..c0d79f192c 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -7711,7 +7711,7 @@ StartupXLOG(void) Insert->fullPageWrites = lastFullPageWrites; LocalSetXLogInsertAllowed(); UpdateFullPageWrites(); - LocalXLogInsertAllowed = -1; + LocalSetXLogInsertCheckRecovery(); if (InRecovery) { @@ -8219,6 +8219,25 @@ LocalSetXLogInsertAllowed(void) InitXLOGAccess(); } +/* + * Make XLogInsertAllowed() return false in the current process only. + */ +void +LocalSetXLogInsertNotAllowed(void) +{ + LocalXLogInsertAllowed = 0; +} + +/* + * Make XLogInsertCheckRecovery() return false in the current process only. + */ +void +LocalSetXLogInsertCheckRecovery(void) +{ + LocalXLogInsertAllowed = -1; +} + + /* * Subroutine to try to fetch and validate a prior checkpoint record. * @@ -9004,9 +9023,9 @@ CreateCheckPoint(int flags) if (shutdown) { if (flags & CHECKPOINT_END_OF_RECOVERY) - LocalXLogInsertAllowed = -1; /* return to "check" state */ + LocalSetXLogInsertCheckRecovery(); /* return to "check" state */ else - LocalXLogInsertAllowed = 0; /* never again write WAL */ + LocalSetXLogInsertNotAllowed(); /* never again write WAL */ } /* @@ -9159,7 +9178,7 @@ CreateEndOfRecoveryRecord(void) END_CRIT_SECTION(); - LocalXLogInsertAllowed = -1; /* return to "check" state */ + LocalSetXLogInsertCheckRecovery(); /* return to "check" state */ } /* diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h index 221af87e71..8c9cadc6da 100644 --- a/src/include/access/xlog.h +++ b/src/include/access/xlog.h @@ -306,6 +306,8 @@ extern RecoveryState GetRecoveryState(void); extern bool HotStandbyActive(void); extern bool HotStandbyActiveInReplay(void); extern bool XLogInsertAllowed(void); +extern void LocalSetXLogInsertNotAllowed(void); +extern void LocalSetXLogInsertCheckRecovery(void); extern void GetXLogReceiptTime(TimestampTz *rtime, bool *fromStream); extern XLogRecPtr GetXLogReplayRecPtr(TimeLineID *replayTLI); extern XLogRecPtr GetXLogInsertRecPtr(void); -- 2.20.1 --MP_/6xG3U2Dzv0UR=.BCNK7fiL6 Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=v5-0002-demote-support-demoting-instance-from-production-to-.patch ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgbench client-side performance issue on large scripts @ 2025-02-24 20:15 Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2025-02-24 20:15 UTC (permalink / raw) To: Daniel Verite <[email protected]>; +Cc: pgsql-hackers "Daniel Verite" <[email protected]> writes: > On large scripts, pgbench happens to consume a lot of CPU time. > For instance, with a script consisting of 50000 "SELECT 1;" > I see "pgbench -f 50k-select.sql" taking about 5.8 secs of CPU time, > out of a total time of 6.7 secs. When run with perf, this profile shows up: You ran only a single execution of a 50K-line script? This test case feels a little bit artificial. Having said that ... > In ParseScript(), expr_scanner_get_lineno() is called for each line > with its current offset, and it scans the script from the beginning > up to the current line. I think that on the whole, parsing this script > ends up looking at (N*(N+1))/2 lines, which is 1.275 billion lines > if N=50000. ... yes, O(N^2) is not nice. It has to be possible to do better. > I wonder whether pgbench should materialize the current line number > in a variable, as psql does in pset.lineno. But given that there are > two different parsers in pgbench, maybe it's not the simplest. > Flex has yylineno but neither pgbench nor psql make use of it. Yeah, we do rely on yylineno in bootscanner.l and ecpg, but not elsewhere; not sure if there's a performance reason for that. I see that plpgsql has a hand-rolled version (look for cur_line_num) that perhaps could be stolen. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgbench client-side performance issue on large scripts @ 2025-02-24 20:30 Tom Lane <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2025-02-24 20:30 UTC (permalink / raw) To: Daniel Verite <[email protected]>; +Cc: pgsql-hackers I wrote: > Yeah, we do rely on yylineno in bootscanner.l and ecpg, but not > elsewhere; not sure if there's a performance reason for that. Ah: the flex manual specifically calls out "%option yylineno" as something that has a moderate performance cost. So that's why we don't use it except in non-performance-critical scanners. Now, it could be argued that pgbench's script scanner doesn't rise to that level of performance-criticalness, especially not if we're paying the cost of counting newlines some other way. I'm not excited about doing a lot of performance analysis here to decide that. I think we could steal plpgsql's idea to keep the code structure basically the same while avoiding the O(N^2) repeat scans, and that should be enough. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-02-24 20:30 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-07-31 08:58 [PATCH 1/4] demote: setter functions for LocalXLogInsert local variable Jehan-Guillaume de Rorthais <[email protected]> 2025-02-24 20:15 Re: pgbench client-side performance issue on large scripts Tom Lane <[email protected]> 2025-02-24 20:30 ` Re: pgbench client-side performance issue on large scripts 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