public inbox for [email protected]help / color / mirror / Atom feed
[PATCH] Remove PROC_IN_ANALYZE 2+ messages / 2 participants [nested] [flat]
* [PATCH] Remove PROC_IN_ANALYZE @ 2020-08-05 22:57 Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Alvaro Herrera @ 2020-08-05 22:57 UTC (permalink / raw) --- src/backend/commands/analyze.c | 13 +------------ src/include/storage/proc.h | 3 +-- src/include/storage/procarray.h | 7 ------- 3 files changed, 2 insertions(+), 21 deletions(-) diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c index 924ef37c81..e0fa73ba79 100644 --- a/src/backend/commands/analyze.c +++ b/src/backend/commands/analyze.c @@ -247,11 +247,8 @@ analyze_rel(Oid relid, RangeVar *relation, } /* - * OK, let's do it. First let other backends know I'm in ANALYZE. + * OK, let's do it. First, initialize progress reporting. */ - LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); - MyPgXact->vacuumFlags |= PROC_IN_ANALYZE; - LWLockRelease(ProcArrayLock); pgstat_progress_start_command(PROGRESS_COMMAND_ANALYZE, RelationGetRelid(onerel)); @@ -279,14 +276,6 @@ analyze_rel(Oid relid, RangeVar *relation, relation_close(onerel, NoLock); pgstat_progress_end_command(); - - /* - * Reset my PGXACT flag. Note: we need this here, and not in vacuum_rel, - * because the vacuum flag is cleared by the end-of-xact code. - */ - LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); - MyPgXact->vacuumFlags &= ~PROC_IN_ANALYZE; - LWLockRelease(ProcArrayLock); } /* diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h index b20e2ad4f6..5ceb2494ba 100644 --- a/src/include/storage/proc.h +++ b/src/include/storage/proc.h @@ -52,7 +52,6 @@ struct XidCache */ #define PROC_IS_AUTOVACUUM 0x01 /* is it an autovac worker? */ #define PROC_IN_VACUUM 0x02 /* currently running lazy vacuum */ -#define PROC_IN_ANALYZE 0x04 /* currently running analyze */ #define PROC_VACUUM_FOR_WRAPAROUND 0x08 /* set by autovac only */ #define PROC_IN_LOGICAL_DECODING 0x10 /* currently doing logical * decoding outside xact */ @@ -60,7 +59,7 @@ struct XidCache /* flags reset at EOXact */ #define PROC_VACUUM_STATE_MASK \ - (PROC_IN_VACUUM | PROC_IN_ANALYZE | PROC_VACUUM_FOR_WRAPAROUND) + (PROC_IN_VACUUM | PROC_VACUUM_FOR_WRAPAROUND) /* * We allow a small number of "weak" relation locks (AccessShareLock, diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h index a5c7d0c064..01040d76e1 100644 --- a/src/include/storage/procarray.h +++ b/src/include/storage/procarray.h @@ -29,8 +29,6 @@ */ #define PROCARRAY_VACUUM_FLAG 0x02 /* currently running lazy * vacuum */ -#define PROCARRAY_ANALYZE_FLAG 0x04 /* currently running - * analyze */ #define PROCARRAY_LOGICAL_DECODING_FLAG 0x10 /* currently doing logical * decoding outside xact */ @@ -42,7 +40,6 @@ * have no corresponding PROC flag equivalent. */ #define PROCARRAY_PROC_FLAGS_MASK (PROCARRAY_VACUUM_FLAG | \ - PROCARRAY_ANALYZE_FLAG | \ PROCARRAY_LOGICAL_DECODING_FLAG) /* Use the following flags as an input "flags" to GetOldestXmin function */ @@ -50,10 +47,6 @@ #define PROCARRAY_FLAGS_DEFAULT PROCARRAY_LOGICAL_DECODING_FLAG /* Ignore vacuum backends */ #define PROCARRAY_FLAGS_VACUUM PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG -/* Ignore analyze backends */ -#define PROCARRAY_FLAGS_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_ANALYZE_FLAG -/* Ignore both vacuum and analyze backends */ -#define PROCARRAY_FLAGS_VACUUM_ANALYZE PROCARRAY_FLAGS_DEFAULT | PROCARRAY_VACUUM_FLAG | PROCARRAY_ANALYZE_FLAG extern Size ProcArrayShmemSize(void); extern void CreateSharedProcArray(void); -- 2.20.1 --Kj7319i9nmIyA2yE-- ^ permalink raw reply [nested|flat] 2+ messages in thread
* Is *fast* 32-bit support still important? @ 2024-07-29 20:40 Joel Jacobson <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Joel Jacobson @ 2024-07-29 20:40 UTC (permalink / raw) To: pgsql-hackers Hello hackers, I would like your help to collectively try to answer these three questions: 1. Who are the current users of 32-bit PostgreSQL? 2. Among these users, how many are upgrading to new major versions? 3. For how many of these users is performance critical? This came up during ongoing work on optimizing numeric_mul [1]. To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with separate 32-bit and 64-bit code paths is worthwhile to maintain performance for both. Knowing more about $subject can hopefully help us reason about how much additional code complication is justifiable for *fast* 32-bit support. I checked the archives but only found a discussion on *dropping* 32-bit support [2], which is a different topic. Thanks for input! /Joel [1] https://postgr.es/m/[email protected] [2] https://postgr.es/m/[email protected] ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-07-29 20:40 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-08-05 22:57 [PATCH] Remove PROC_IN_ANALYZE Alvaro Herrera <[email protected]> 2024-07-29 20:40 Is *fast* 32-bit support still important? Joel Jacobson <[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