Re: check for null value before looking up the hash function
От | Ranier Vilela |
---|---|
Тема | Re: check for null value before looking up the hash function |
Дата | |
Msg-id | CAEudQArLQ4iCAPTs3-n=L6UmKwvV8F+p7tdA2887DAXYMmO3GA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: check for null value before looking up the hash function (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: check for null value before looking up the hash function
Re: check for null value before looking up the hash function |
Список | pgsql-hackers |
Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra <tomas.vondra@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.
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
В списке pgsql-hackers по дате отправления: