Hi,
On 2017-10-13 13:06:41 -0400, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 2:12 AM, Andres Freund <andres@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.
Thanks!
> + /* 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.
K.
> - 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.
Yea, that'd be nice - it does show up in profiles. I'd tried to do
that, but it's not exactly trivial, so I decided to delay it. The
ordering when syscache stuff gets initialized is, uh, fragile. During
InitCatalogCache() the catalog is not ready for access. After that, we
access catcaches while not all catalogs are quite ready to be accessed.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
