Prevent generating index-only "Path"s for columnar tables

Previously, even when `EXPLAIN` output tells that we will do
index-only scan, it was never the case since columnar tables
don't have the visibility fork that postgres is looking for.

For this reason, visibility check done in
`IndexOnlyNext->VM_ALL_VISIBLE`
code-path was always returning false and postgres was reading
the tuple from the columnar relation itself.

src/backend/columnar/columnar_customscan.c

@@ -344,6 +344,13 @@ ColumnarGetRelationInfoHook(PlannerInfo *root, Oid relationObjectId,
 	{
 		/* disable parallel query */
 		rel->rel_parallel_workers = 0;
+
+		/* disable index-only scan */
+		IndexOptInfo *indexOptInfo = NULL;
+		foreach_ptr(indexOptInfo, rel->indexlist)
+		{
+			memset(indexOptInfo->canreturn, false, indexOptInfo->ncolumns);
+		}
 	}
 }
 

src/test/regress/expected/columnar_indexes.out

@@ -111,9 +111,9 @@ EXPLAIN (COSTS OFF) SELECT * FROM columnar_table WHERE a=6456;
 (2 rows)
 
 EXPLAIN (COSTS OFF) SELECT a FROM columnar_table WHERE a=6456;
-                          QUERY PLAN
+                       QUERY PLAN
 ---------------------------------------------------------------------
- Index Only Scan using columnar_table_a_idx on columnar_table
+ Index Scan using columnar_table_a_idx on columnar_table
    Index Cond: (a = 6456)
 (2 rows)
 
@@ -183,9 +183,9 @@ EXPLAIN (COSTS OFF) SELECT b FROM columnar_table WHERE b = 30000;
 
 -- can use index scan
 EXPLAIN (COSTS OFF) SELECT b FROM columnar_table WHERE b = 30001;
-                          QUERY PLAN
+                       QUERY PLAN
 ---------------------------------------------------------------------
- Index Only Scan using columnar_table_b_idx on columnar_table
+ Index Scan using columnar_table_b_idx on columnar_table
    Index Cond: (b = 30001)
 (2 rows)
 
@@ -343,9 +343,9 @@ SELECT pg_total_relation_size ('unique_a') * 1.5 <
 DROP INDEX unique_a;
 -- should use index only scan since unique_a_include_b_c_d includes column "b" too
 EXPLAIN (COSTS OFF) SELECT b FROM include_test WHERE a = 500;
-                          QUERY PLAN
+                       QUERY PLAN
 ---------------------------------------------------------------------
- Index Only Scan using unique_a_include_b_c_d on include_test
+ Index Scan using unique_a_include_b_c_d on include_test
    Index Cond: (a = 500)
 (2 rows)
 

src/test/regress/expected/columnar_paths.out

@@ -354,7 +354,7 @@ LIMIT 100;
                                  ->  GroupAggregate
                                        Group Key: full_correlated_1.a
                                        Filter: (count(DISTINCT full_correlated_1.a) >= 1)
-                                       ->  Index Only Scan Backward using full_correlated_btree on full_correlated full_correlated_1
+                                       ->  Index Scan Backward using full_correlated_btree on full_correlated full_correlated_1
                                              Index Cond: (a > 10)
                ->  Materialize
                      ->  Subquery Scan on sub_3
@@ -610,12 +610,11 @@ SELECT * FROM correlated WHERE x = 78910;
 -- should choose index scan; selective but uncorrelated
 EXPLAIN (analyze on, costs off, timing off, summary off)
 SELECT * FROM uncorrelated WHERE x = 78910;
-                                   QUERY PLAN
+                                QUERY PLAN
 ---------------------------------------------------------------------
- Index Only Scan using uncorrelated_idx on uncorrelated (actual rows=1 loops=1)
+ Index Scan using uncorrelated_idx on uncorrelated (actual rows=1 loops=1)
    Index Cond: (x = 78910)
-   Heap Fetches: 1
+(2 rows)
-(3 rows)
 
 SELECT * FROM uncorrelated WHERE x = 78910;
    x