Re: [PATCH] Covering SPGiST index
От | Pavel Borisov |
---|---|
Тема | Re: [PATCH] Covering SPGiST index |
Дата | |
Msg-id | CALT9ZEFCHtocjujVK2F3wS6Ldr_M+20qXyQdtam2_-pWRxg0kw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Covering SPGiST index (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I've committed this with a lot of mostly-cosmetic changes.
The not-so-cosmetic bits had to do with confusion between
the input data type and the leaf type, which isn't really
your fault because it was there before :-(.
One note is that I dropped the added regression test script
(index_including_spgist.sql) entirely, because I couldn't
see that it did anything that justified a permanent expenditure
of test cycles. It looks like you made that by doing s/gist/spgist/g
on index_including_gist.sql, which might be all right except that
that script was designed to test GiST-specific implementation concerns
that aren't too relevant to SP-GiST. AFAICT, removing that script had
exactly zero effect on the test coverage shown by gcov. There are
certainly bits of spgist that are depressingly under-covered, but I'm
afraid we need custom-designed test cases to get at them.
(wanders away wondering if the isolationtester could be used to test
the concurrency-sensitive parts of spgvacuum.c ...)
regards, tom lane
Thanks a lot!
As for tests I mostly checked the storage and reconstruction of included attributes in the spgist index with radix and quadtree, with many included columns of different types and nulls among the values. But I consider it too big for regression. I attach radix test just in case. Do you consider something like this could be useful for testing and should I try to adapt something like this to make regression? Or do something like this on some database already in the regression suite?
Вложения
В списке pgsql-hackers по дате отправления: