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]>
2025-02-24 20:30 ` Re: pgbench client-side performance issue on large scripts 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:15 Re: pgbench client-side performance issue on large scripts Tom Lane <[email protected]>
@ 2025-02-24 20:30 ` 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