Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 - Mailing list pgsql-hackers

From Japin Li
Subject Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Date
Msg-id ME0P300MB04457AAC931AD1E3D0CE32FBB628A@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [WIP]Vertical Clustered Index (columnar store extension) - take2  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
List pgsql-hackers
On Fri, Aug 08, 2025 at 06:08:27PM +1000, Peter Smith wrote:
> Here are the latest v17 patches.
> 
> Changes include:
> 
> PATCH 0002.
> - Rebase to fix compile error, result of recent master change
> - Bugfix for an unreported EXPLAIN ANALYZE error
> - Bugfix for an unreported double pfree
> - Code cleanup (ran pgindent; corrected ~100 typos; removed empty
> coverage comments)
> 

1.
+static struct
+{
+    int         transfn_oid;    /* Transition function's funcoid. Arrays are
+                                 * sorted in ascending order */
+    Oid         transtype;      /* Transition data type */
+    PGFunction  merge_trans;    /* Function pointer set required for parallel
+                                 * aggregation for each transfn_oid */
+    vci_aggtranstype_kind kind; /* If transtype is INTERNALOID, its details */
+}           trans_funcs_table[] = {
+    {F_FLOAT4_ACCUM, 1022, merge_floatX_accum, VCI_AGG_NOT_INTERNAL},   /* 208 */
+    {F_FLOAT8_ACCUM, 1022, merge_floatX_accum, VCI_AGG_NOT_INTERNAL},   /* 222 */
+    {F_INT8INC, 20, int8pl, VCI_AGG_NOT_INTERNAL},  /* 1833 */
+    {F_NUMERIC_ACCUM, 2281, numeric_combine, VCI_AGG_NUMERIC_AGG_STATE},    /* 1834 */
+    {F_INT2_ACCUM, 2281, numeric_poly_combine, VCI_AGG_POLY_NUM_AGG_STATE}, /* 1836 */
+    {F_INT4_ACCUM, 2281, numeric_poly_combine, VCI_AGG_POLY_NUM_AGG_STATE}, /* 1835 */
+    {F_INT8_ACCUM, 2281, numeric_combine, VCI_AGG_NUMERIC_AGG_STATE},   /* 1836 */
+    {F_INT2_SUM, 20, int8pl, VCI_AGG_NOT_INTERNAL}, /* 1840 */
+    {F_INT4_SUM, 20, int8pl, VCI_AGG_NOT_INTERNAL}, /* 1841 */
+    {F_INTERVAL_AVG_COMBINE, 2281, merge_interval_avg_accum, VCI_AGG_NOT_INTERNAL}, /* 3325 */
+    {F_INT2_AVG_ACCUM, 1016, merge_intX_accum, VCI_AGG_NOT_INTERNAL},   /* 1962 */
+    {F_INT4_AVG_ACCUM, 1016, merge_intX_accum, VCI_AGG_NOT_INTERNAL},   /* 1963 */
+    {F_INT8INC_ANY, 20, int8pl, VCI_AGG_NOT_INTERNAL},  /* 2804 */
+    {F_INT8_AVG_ACCUM, 2281, int8_avg_combine, VCI_AGG_POLY_AVG_NUM_AGG_STATE}, /* 2746 */
+    {F_NUMERIC_AVG_ACCUM, 2281, numeric_avg_combine, VCI_AGG_AVG_NUMERIC_AGG_STATE},    /* 2858 */
+};

The comments state that this is sorted in ascending order, but the code doesn't
follow that rule. While the current linear search works, a future change to
binary search could cause problems.

2.
+static void
+CheckIndexedRelationKind(Relation rel)
+{
+    char        relKind = get_rel_relkind(RelationGetRelid(rel));
+
+    if (relKind == RELKIND_MATVIEW)
+        ereport(ERROR,
+                (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                 errmsg("access method \"%s\" does not support index on materialized view", VCI_STRING)));
+
+    if (rel->rd_rel->relpersistence == RELPERSISTENCE_TEMP)
+        ereport(ERROR,
+                (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                 errmsg("access method \"%s\" does not support index on temporary table", VCI_STRING)));
+}

Would it be possible to use rel->rd_rel->relkind directly?  This might avoid
the overhead of a function call.

3.
The discussion on add_index_delete_hook [1] makes me wonder if an Index Access
Method callback could serve the same purpose. This also raises the question:
would we then need an index update callback as well?

3.
Here are some typos.

a)
@@ -475,7 +477,7 @@ vci_scan_EndCustomPlan(CustomScanState *node)

         default:
             /* LCOV_EXCL_START */
-            elog(PANIC, "Should not reach hare");
+            elog(PANIC, "Should not reach here");
             /* LCOV_EXCL_STOP */
             break;
     }
b)
@@ -543,7 +545,7 @@ vci_create_relation(const char *rel_identifier, Relation indexRel, IndexInfo *in
             TupleDescInitEntry(new_tupdesc, (AttrNumber) 1, "bindata", BYTEAOID, -1, 0);    /* */
             break;

-            /* TIC-CRID  */
+            /* TID-CRID  */
         case VCI_RELTYPE_TIDCRID:
             natts = 1;
             new_tupdesc = CreateTemplateTupleDesc(natts);   /* no Oid */

c)
@@ -1065,7 +1065,7 @@ vci_inner_build(Relation heapRel, Relation indexRel, IndexInfo *indexInfo)
 /*
  * Put or Copy page into INIT_FORK.
  * If valid page is given, that page will be putted into INIT_FORK.
- * If Invalid page (NULL pointer) is given, MAIN_FORK page well be copied.
+ * If invalid page (NULL pointer) is given, MAIN_FORK page well be copied.
  */
 static void
 vci_putInitPage(Oid oid, Page page, BlockNumber blkno)


[1]
https://www.postgresql.org/message-id/OS7PR01MB119642862AA1CE536549D08CFEA40A%40OS7PR01MB11964.jpnprd01.prod.outlook.com

-- 
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.

Attachment

pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Parallel Apply
Next
From: jian he
Date:
Subject: Re: alter check constraint enforceability