Re: [PATCH] Covering SPGiST index
От | Andrey M. Borodin |
---|---|
Тема | Re: [PATCH] Covering SPGiST index |
Дата | |
Msg-id | FBAB54E5-F666-4DB2-BDB7-22B20CF38BF3@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: [PATCH] Covering SPGiST index (Pavel Borisov <pashkin.elfe@gmail.com>) |
Ответы |
Re: [PATCH] Covering SPGiST index
|
Список | pgsql-hackers |
> 27 авг. 2020 г., в 21:03, Pavel Borisov <pashkin.elfe@gmail.com> написал(а): > > see v8 For me is the only concerning point is putting nullmask and varatt bits into tuple->nextOffset. But, probably, we can go with this. But let's change macro a bit. When I see SGLT_SET_OFFSET(leafTuple->nextOffset, InvalidOffsetNumber); I expect that leafTuple->nextOffset is function argument by value and will not be changed. For example see ItemPointerSetOffsetNumber() - it's not exposing ip_posid. Also, I'd propose instead of >*(leafChainDatums + i * natts) and leafChainIsnulls + i * natts using something like >int some_index = i * natts; >leafChainDatumsp[some_index] and &leafChainIsnulls[some_index] But, probably, it's a matter of taste... Also I'm not sure would it be helpful to use instead of >isnull[0] and leafDatum[0] more complex >#define SpgKeyIndex 0 >isnull[SpgKeyIndex] and leafDatum[SpgKeyIndex] There is so many [0] in the patch... Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: