Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu:
> > > On 5/21/22 15:06, Ranier Vilela wrote: > >>Zhihong Yu <zyu(at)yugabyte(dot)com> writes: > >>> I was looking at the code in hash_record() > >>> of src/backend/utils/adt/rowtypes.c > >>> It seems if nulls[i] is true, we don't need to look up the hash > function. > > > >>I don't think this is worth changing. It complicates the logic, > >>rendering it unlike quite a few other functions written in the same > >>style. In cases where the performance actually matters, the hash > >>function is cached across multiple calls anyway. You might save > >>something if you have many calls in a query and not one of them > >>receives a non-null input, but how likely is that? > > > > I disagree. > > I think that is worth changing. The fact of complicating the logic > > is irrelevant. > > That's a quite bold claim, and yet you haven't supported it by any > argument whatsoever. Trade-offs between complexity and efficiency are a > crucial development task, so complicating the logic clearly does matter. > What I meant is that complicating the logic in search of efficiency is worth it, and that's what everyone is looking for in this thread. Likewise, not complicating the logic, losing a little bit of efficiency, applied to all the code, leads to a big loss of efficiency. In other words, I never miss an opportunity to gain efficiency. regards, Ranier Vilela
