From: | John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | generating catcache control data |
Date: | 2019-10-10 08:30:52 |
Message-ID: | CACPNZCvMiAJ-XX2MGvHD4Kzt_fTxxmM0rf7LWURr9Xd+Wy=uZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
While digging through the archives, I found a thread from a couple
years back about syscache performance. There was an idea [1] to
generate the cache control data at compile time. That would to remove
the need to perform database access to complete cache initialization,
as well as the need to check in various places whether initialization
has happened.
If this were done, catcache.c:InitCatCachePhase2() and
catcache.c:CatalogCacheInitializeCache() would disappear, and
syscache.c:InitCatalogCachePhase2() could be replaced by code that
simply opens the relations when writing new init files. Another
possibility this opens up is making the SysCacheRelationOid and
SysCacheSupportingRelOid arrays constant data as well.
Here's a basic design sketch:
1. Generate the current syscache cacheinfo[] array and cacheid enum by
adding a couple arguments to the declarations for system indexes, as
in:
#define DECLARE_UNIQUE_INDEX(name,oid,oid_macro,cacheid,num_buckets,decl)
extern int no_such_variable
DECLARE_UNIQUE_INDEX(pg_amop_opr_fam_index, 2654,
AccessMethodOperatorIndexId, AMOPOPID, 64, on pg_amop using
btree(amopopr oid_ops, amoppurpose char_ops, amopfamily oid_ops));
DECLARE_UNIQUE_INDEX(pg_amop_oid_index, 2756,
AccessMethodOperatorOidIndexId, -, 0, on pg_amop using btree(oid
oid_ops));
...and add in data we already know how to parse from the catalog
headers. Note that the last example has '-' and '0' to mean "no
cache". (The index oid macro is superfluous there, but kept for
consistency.)
2. Expand the cacheinfo[] element structs with the rest of the constant data:
Relname, and relisshared are straightforward. For eq/hash functions,
we could add metadata attributes to pg_type.dat for the relevant
types. Tuple descriptors would get their attrs from schemapg.h.
3. Simplify cat/syscache.c
Is this something worth doing?
[1] https://www.postgresql.org/message-id/1295.1507918074%40sss.pgh.pa.us
--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2019-10-10 08:39:28 | Re: maintenance_work_mem used by Vacuum |
Previous Message | Amit Langote | 2019-10-10 08:28:02 | Re: dropping column prevented due to inherited index |