Re: Covering GiST indexes

On 11/26/18 5:56 PM, Andrey Borodin wrote:
> Here's rebased version. Thanks!

Here is my review.

= General

The features seems useful and an obvious extension of covering B-trees,
and a potentially useful feature together with exclusion constraints.

The patch still applies (with git apply -3), compiles and passes the
test suite.

From some testing it seems like it works as expected.

= Code

* Have some minor style issues like that there should be spaces around
|| (in gistcanreturn()) and ? and : (in gistFormTuple()).

* I do not see any need for adding the new parameter to gistFormTuple.
As far as I can tell isTruncated is always equal to !isleaf.

* The comment below from gistFormTuple() does not look correct. No
allocation is taking place.

/*
* Allocate each included attribute.
*/

* Why do you set a supportCollation for the included columns? As far as
I can tell the collation is only used by the various GiST support
functions. Also in theory we should be able to skip initializing these
array entires, but it is probably for the best that we do.

* I think you should check for the attno first in gistcanreturn() to
take advantage of the short circuiting.

* I am no fan of the tupdesc vs truncTupdesc separation and think that
it is a potential hazard, but I do not have any better suggestion right now.

* There is no test case for exclusion constraints, and I feel since that
is one of the more important uses we should probably have at least one
such test case.

= Minor comments

* I think that "the" should have been kept in the text below.

- Currently, only the B-tree index access method supports this
feature.
+ Currently, B-tree and GiST index access methods supports this
feature.

* I am not a native speaker but I think it should be "use the INCLUDE
clause" in the diff below, and I think it also should be "without any
GiST operator class".

+ A GiST index can be covering, i.e. use <literal>INCLUDE</literal>
clause.
+ Included columns can have data types without GiST operator class.
Included
+ attributes will be stored uncompressed.

* I think you should write something like "Included attributes always
support index-only scans." rather than "Included attributes can be
returned." in the comment for gistcanreturn().

* Why the random noise in the diff below? I think using "(c3) INCLUDE
(c4)" for both gist and rtree results in a cleaner patch.

CREATE TABLE tbl (c1 int,c2 int, c3 box, c4 box);
CREATE INDEX on tbl USING brin(c1, c2) INCLUDE (c3, c4);
-CREATE INDEX on tbl USING gist(c3) INCLUDE (c4);
+CREATE INDEX on tbl USING gist(c4) INCLUDE (c3);
CREATE INDEX on tbl USING spgist(c3) INCLUDE (c4);
CREATE INDEX on tbl USING gin(c1, c2) INCLUDE (c3, c4);
CREATE INDEX on tbl USING hash(c1, c2) INCLUDE (c3, c4);
-CREATE INDEX on tbl USING rtree(c1, c2) INCLUDE (c3, c4);
+CREATE INDEX on tbl USING rtree(c4) INCLUDE (c3, c1);
CREATE INDEX on tbl USING btree(c1, c2) INCLUDE (c3, c4);