Re: [PATCH] Covering SPGiST index - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: [PATCH] Covering SPGiST index
Date
Msg-id CALT9ZEFCHtocjujVK2F3wS6Ldr_M+20qXyQdtam2_-pWRxg0kw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Covering SPGiST index  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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?

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com
Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: UniqueKey on Partitioned table.
Next
From: Fujii Masao
Date:
Subject: Re: Stronger safeguard for archive recovery not to miss data