Hi,
On 2021-08-31 15:06:32 -0400, John Naylor wrote:
> Were you thinking in terms of passing the type oid in parameters, like this?
>
> HeapTuple
> SearchCatCache1(CatCache *cache, Datum v1, Oid t1)
> {
> return SearchCatCacheInternal(cache, 1, v1, t1, 0, 0, 0, 0, 0, 0);
> }
>
> And then CatalogCacheComputeHashValue() and CatalogCacheCompareTuple()
> would likewise take types as parameters, which they could use to pick the
> right functions at compile time?
I was thinking that the script could emit something like
static const cachedesc syscachedesc_AGGFNOID = {
.reloid = AggregateRelationId,
.indoid = AggregateFnoidIndexId,
.nkeys = 1,
.keys = {
{
.varno = Anum_pg_aggregate_aggfnoid,
.type = Oid,
.comparator = ...
}
}
};
static CatCache syscache_AGGFNOID;
HeapTuple
SearchSysCacheAGGFNOID(Datum key1)
{
return SearchSysCacheInternal(&syscachedesc_AGGFNOID, syscache_AGGFNOID, key1);
}
and SearchSysCacheInternal would have a pg_attribute_always_inline()
fastpath. That fastpath would basically be SearchCatCacheInternal(), with an
extra const cachedesc * paramter. Then the compiler should be able to generate
direct function calls to the hash functions in CatalogCacheComputeHashValue()
and direct calls to the equal function in CatalogCacheCompareTuple().
One difficulty would be that I don't see how to make this work with syscache.c
being compiled separately from catcache.c - but there's probably no need
to. The script could generate a syscache_impl.h that catcache.c includes.
Greetings,
Andres Freund