Re: [PATCH] Reduce pg_class scans in GRANT/REVOKE ON ALL TABLES IN SCHEMA - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Reduce pg_class scans in GRANT/REVOKE ON ALL TABLES IN SCHEMA
Date
Msg-id adw8FBNktrUjlsLc@paquier.xyz
Whole thread Raw
In response to [PATCH] Reduce pg_class scans in GRANT/REVOKE ON ALL TABLES IN SCHEMA  (CharSyam <charsyam@gmail.com>)
Responses Re: [PATCH] Reduce pg_class scans in GRANT/REVOKE ON ALL TABLES IN SCHEMA
List pgsql-hackers
On Sun, Apr 12, 2026 at 04:22:24PM +0900, CharSyam wrote:
>   Benchmark
>   ---------
>   This is a targeted micro-optimization, not a dramatic speedup.
>   With 10,000 tables in a single schema (pg_class ~10,452 rows),
>   running GRANT/REVOKE SELECT ON ALL TABLES IN SCHEMA in a loop
>   (6 iterations, first dropped as warmup), I measured a consistent
>   ~15% reduction in end-to-end time:
>
>                        baseline    patched     delta
>       GRANT  (avg)     88.2 ms     75.9 ms    -14%
>       REVOKE (avg)    134.9 ms    115.7 ms    -14%

I am pretty sure that there are users with millions of relations in a
single schema that could benefit from that.  At least that would not
be surprising with partitioning these days, and foreign tables.  What
kind of numbers do you get if you bump up the number of digits for
these tests.  Let's say a comparison based on a few million relations
at least?

The change you are proposing looks simple enough, quickly skimming
through the patch.  There may be more optimizations doable here, I
have not looked at that, still I tend to like such micro-optimization
proposals as they provide a silent benefit.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: test_compression, test module for low-level compression APIs (for 2b5ba2a0a141)
Next
From: Chao Li
Date:
Subject: Re: Fix pgstat_database.c to honor passed database OIDs