Re: turn fastgetattr and heap_getattr to inline functions

From: Japin Li <japinli(at)hotmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: turn fastgetattr and heap_getattr to inline functions
Date: 2022-03-24 15:41:43
Message-ID: ME3P282MB1667663F3D30DBCFC984E85DB6199@ME3P282MB1667.AUSP282.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Thu, 24 Mar 2022 at 22:32, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2022-Mar-24, Japin Li wrote:
>
>> I want to know why we do not use the following style?
>>
>> +static inline Datum
>> +heap_getattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, bool *isnull)
>> +{
>> + if (attnum > 0)
>> + {
>> + if (attnum > (int) HeapTupleHeaderGetNatts(tup->t_data))
>> + return getmissingattr(tupleDesc, attnum, isnull);
>> + else
>> + return fastgetattr(tup, attnum, tupleDesc, isnull);
>> + }
>> +
>> + return heap_getsysattr(tup, attnum, tupleDesc, isnull);
>> +}
>
> That was the first thing I wrote, but I can't get myself to like it.
> For this one function the code flow is obvious enough; but if you apply
> the same idea to fastgetattr(), the result is not nice at all.
>
> If there are enough votes for doing it this way, I can do that.
>
> I guess we could do something like this instead, which seems somewhat
> less bad:
>
> if (attnum <= 0)
> return heap_getsysattr(...)
> if (likely(attnum <= HeapTupleHeaderGetNattrs(...)))
> return fastgetattr(...)
>
> return getmissingattr(...)
>
> but I still prefer the one in the v2 patch I posted.
>
> It's annoying that case 0 (InvalidAttrNumber) is not well handled
> anywhere.

Thanks for your detail explaination. I find bottomup_sort_and_shrink_cmp()
has smilar code

static int
bottomup_sort_and_shrink_cmp(const void *arg1, const void *arg2)
{
const IndexDeleteCounts *group1 = (const IndexDeleteCounts *) arg1;
const IndexDeleteCounts *group2 = (const IndexDeleteCounts *) arg2;

[...]

pg_unreachable();

return 0;
}

IIUC, the last statement is used to keep the compiler quiet. However,
it doesn't exist in LWLockAttemptLock(). Why?

The difference between bottomup_sort_and_shrink_cmp() and LWLockAttemptlock()
is that LWLockAttemptlock() always returned before pg_unreachable(), however,
bottomup_sort_and_shrink_cmp() might be returned after pg_unreachable(), which
isn't expected.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2022-03-24 15:43:25 Re: Documenting when to retry on serialization failure
Previous Message Andres Freund 2022-03-24 15:40:00 Re: [RFC] building postgres with meson -v6