From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: RFC: Improve CPU cache locality of syscache searches |
Date: | 2021-08-27 19:42:04 |
Message-ID: | 20210827194204.iun2hts7trrqynir@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> diff --git a/src/include/utils/catcache_search_template.h b/src/include/utils/catcache_search_template.h
> new file mode 100644
> index 0000000000..6f5dc2573c
> --- /dev/null
> +++ b/src/include/utils/catcache_search_template.h
> @@ -0,0 +1,176 @@
> +/*-------------------------------------------------------------------------
> + * catcache_search_template.h
> + *
> + * A template for type-specialized SearchCatCache functions
> + *
> + * Usage notes:
> + *
> + * 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?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-08-27 19:43:07 | Re: log_autovacuum in Postgres 14 -- ordering issue |
Previous Message | Andres Freund | 2021-08-27 19:38:13 | Re: Estimating HugePages Requirements? |