replace magic num in struct cachedesc with CATCACHE_MAXKEYS

Started by Junwang Zhaoabout 2 years ago3 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

appliessuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50121
psql -h localhost -U postgres

Built from patchset v1 (message #1), September 20, 2026 at 04:20 AM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t50121_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t50121_1 && git checkout t50121_1

Patchset v1 (message #1) is on t50121_1

Jump to latest
#1Junwang Zhao
zhjwpku@gmail.com

Hi hackers,

I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.

I did some search on pg-hackers, and found an old thread[0]/messages/by-id/603c8f071003281532t5e6c68eex458825485d4fcd98@mail.gmail.com that
Robert proposed to change
the maximum number of keys for a syscache from 4 to 5.

It seems to me that the *five-key syscaches* feature is not necessary
since the idea was
14 years old and we still use 4 keys without any problems(I might be wrong).

However, in that patch, there is a change that seems reasonable.

--- a/src/backend/utils/cache/syscache.c
+++ b/src/backend/utils/cache/syscache.c
@@ -95,7 +95,7 @@ struct cachedesc
        Oid                     reloid;                 /* OID of the
relation being cached */
        Oid                     indoid;                 /* OID of
index relation for this cache */
        int                     nkeys;                  /* # of keys
needed for cache lookup */
-       int                     key[4];                 /* attribute
numbers of key attrs */
+       int                     key[CATCACHE_MAXKEYS];  /* attribute
numbers of key attrs */
        int                     nbuckets;               /* number of
hash buckets for this cache */
 };

[0]: /messages/by-id/603c8f071003281532t5e6c68eex458825485d4fcd98@mail.gmail.com

--
Regards
Junwang Zhao

Attachments:

t50121_1
v1-0001-replace-magic-num-with-CATCACHE_MAXKEYS.patchapplication/octet-stream; name=v1-0001-replace-magic-num-with-CATCACHE_MAXKEYS.patchDownload+1-2
#2Peter Eisentraut
peter_e@gmx.net
In reply to: Junwang Zhao (#1)
Re: replace magic num in struct cachedesc with CATCACHE_MAXKEYS

On 15.08.24 12:25, Junwang Zhao wrote:

I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.

The "syscache" is the only user of the "catcache" right now. But I
think they are formally separate. So I don't think the "4" in the
syscache is necessarily the same as CATCACHE_MAXKEYS. For example,
increasing CATCACHE_MAXKEYS, hypothetically, wouldn't by itself make the
syscache support more than 4 keys.

#3Junwang Zhao
zhjwpku@gmail.com
In reply to: Peter Eisentraut (#2)
Re: replace magic num in struct cachedesc with CATCACHE_MAXKEYS

On Fri, Aug 23, 2024 at 9:02 PM Peter Eisentraut <peter@eisentraut.org> wrote:

On 15.08.24 12:25, Junwang Zhao wrote:

I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.

The "syscache" is the only user of the "catcache" right now. But I
think they are formally separate. So I don't think the "4" in the
syscache is necessarily the same as CATCACHE_MAXKEYS. For example,
increasing CATCACHE_MAXKEYS, hypothetically, wouldn't by itself make the
syscache support more than 4 keys.

Thanks for your explanation.

CF status changed to withdrawn.

--
Regards
Junwang Zhao