Re: [PATCH] Covering SPGiST index

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: [PATCH] Covering SPGiST index
Дата
Msg-id CALT9ZEHEiwW4riEyRgp0otBs=FPf0m38MnkryeE8z0L1b1B4bQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Covering SPGiST index  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Ответы Re: [PATCH] Covering SPGiST index  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I have a wild idea of renaming nextOffset in SpGistLeafTupleData.
Or at least documenting in comments that this field is more than just an offset.
Seems reasonable as previous changes localized mentions of nextOffset only to leaf tuple definition and access macros. So I've done this renaming.
 
This looks like assert rather than real runtime check in spgLeafTupleSize()

+               if (state->includeTupdesc->natts + 1 >= INDEX_MAX_KEYS)
+                       ereport(ERROR,
+                                       (errcode(ERRCODE_TOO_MANY_COLUMNS),
+                                        errmsg("number of index columns (%d) exceeds limit (%d)",
+                                                       state->includeTupdesc->natts, INDEX_MAX_KEYS)));
Even if you go with check, number of columns is state->includeTupdesc->natts  + 1.
I placed this check only once on SpGist state creation and replaced the other checks to asserts.
 
Also I'd refactor this
+       /* Form descriptor for INCLUDE columns if any */
Also done. Thanks a lot!
See v10.


--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: builtin functions, parameter names and psql's \df
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: A micro-optimisation for walkdir()