From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: RFC: Improve CPU cache locality of syscache searches |
Date: | 2021-08-31 19:06:32 |
Message-ID: | CAFBsxsF7+s=_AeV8X8v3PWO2509kJurXs9z8wh=A0_sX6tmEAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 27, 2021 at 3:42 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2021-08-19 19:10:37 -0400, John Naylor wrote:
> > I've made a small step in this direction in the attached. It uses a
> > template approach to generate type-specific SearchCatCache* functions,
for
> > now only the 4-key ones. Since there's only a few of those, it's
manageable
> > to invoke the template and change the call sites by hand. To get this to
> > scale up to all syscaches would require some scripting, but this much is
> > enough to get feedback on the approach. One possible concern in starting
> > down this path is that hundreds of call sites would have to be changed.
(If
> > there's a good way around that, it hasn't occurred to me.)
>
> I was thinking of avoiding the need for that via a macro. I.e. have
> SearchSysCache4(AMOPSTRATEGY, ...) be mapped to
> SearchSysCache4AMOPSTRATEGY(...). That way callers wouldn't need to care,
and
> we could continue to evolve the internals without continually doing
> large-scale code changes?
Makes sense.
> > + * To generate functions specialized for a set of catcache keys,
> > + * the following parameter macros should be #define'd before this
> > + * file is included.
> > + *
> > + * - CC_SEARCH - the name of the search function to be generated
> > + * - CC_NKEYS - the number of search keys for the tuple
> > + * - FASTEQFUNCx (x in 1,2,3,4) - type-specific equality function(s)
> > + * - HASHFUNCx (x in 1,2,3,4) - type-specific hash function(s)
>
> It's not clear to me we need such a complicated interface here. Can't we
just
> have a pg_attribute_always_inline function with a bunch more parameters?
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?
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-08-31 19:07:09 | Re: mark the timestamptz variant of date_bin() as stable |
Previous Message | Tom Lane | 2021-08-31 19:06:25 | Re: Can we get rid of repeated queries from pg_dump? |