On Mon, Oct 12, 2020 at 05:46:16AM -0400, John Naylor wrote: > Hmm, I hadn't actually, but now that you mention it, that looks worth > optimizing that as well, since there are multiple callers that search that > table -- thanks for the reminder. The attached patch was easy to whip up, > being similar to the quick check (doesn't include the pg_hton32 fix). I'll > do some performance testing soon. Note that a 25kB increase in size could > be present in frontend binaries as well in this case. While looking at > decomposition, I noticed that recomposition does a linear search through > all 6600+ entries, although it seems only about 800 are valid for that. > That could be optimized as well now, since with hashing we have more > flexibility in the ordering and can put the recomp-valid entries in front. > I'm not yet sure if it's worth the additional complexity. I'll take a look > and start a new thread.
Starting a new thread for this topic sounds like a good idea to me, with a separate performance analysis. Thanks! -- Michael
signature.asc
Description: PGP signature
