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