Re: [PATCH] Covering SPGiST index

>
> 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?

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>