On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund <and...@anarazel.de> wrote: > This patch gives me roughly 8% speedup in a workload that consists out > of a fast query that returns a lot of columns. If I apply a few > other performance patches, this patch itself starts to make a bigger > difference, of around 11%.
I did a read-through of this patch today. I don't see anything really serious to complain about here. Somebody might question the use of the no-inline stuff, but it seems sensible to me in this context. + /* not as performance critical & "complicated" */ This comment kinda sucks. I don't think it will be clear to somebody in 3 years what this means. It's clear enough in context but later I think it won't be. I suggest dumping this altogether and expanding the comment up above to encompass this: Hash and equality functions for system types that are used as cache key fields. In some cases, we just call the regular SQL-callable functions for the appropriate data type, but that tends to be a little slow, and the speed of these functions is performance-critical. Therefore, for data types that frequently occur as catcache keys, we hard-code the logic here. Avoiding the overhead of DirectFunctionCallN(...) is a substantial win, and in certain cases (like int4) we can adopt a faster hash algorithm as well. + { + return false; + } Excess braces. + * The use of argument specific numbers is encouraged, they're faster, and + * insulates the caller from changes in the maximum number of keys. s/, they're faster/. They're faster/ - if (cache->cc_tupdesc == NULL) + if (unlikely(cache->cc_tupdesc == NULL)) CatalogCacheInitializeCache(cache); I don't think it's this patch's job to do it, but it seems like we ought to just invent some early-initialization step where things like this can happen, so that we don't have to branch here at all. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers