Pg18 - missing Index Scan on pg_class

[m3hm3t]

diff -dU10 -w /__w/citus/citus/src/test/regress/expected/multi_mx_hide_shard_names.out /__w/citus/citus/src/test/regress/results/multi_mx_hide_shard_names.out
--- /__w/citus/citus/src/test/regress/expected/multi_mx_hide_shard_names.out.modified	2025-10-17 11:46:12.512182101 +0000
+++ /__w/citus/citus/src/test/regress/results/multi_mx_hide_shard_names.out.modified	2025-10-17 11:46:12.526182131 +0000
@@ -116,25 +116,24 @@
      LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 WHERE c.relname OPERATOR(pg_catalog.~) '^(test_table)$' COLLATE pg_catalog.default
   AND pg_catalog.pg_table_is_visible(c.oid)
 ORDER BY 2, 3;
                                                                 QUERY PLAN                                                                
 ------------------------------------------------------------------------------------------------------------------------------------------
  Sort
    Sort Key: n.nspname, c.relname
    ->  Nested Loop Left Join
          Join Filter: (n.oid = c.relnamespace)
-         ->  Index Scan using pg_class_relname_nsp_index on pg_class c
-               Index Cond: (relname = 'test_table'::text)
+         ->  Seq Scan on pg_class c

[colm-mchugh]

This is likely PG18's planner preferring a sequential scan over an index scan, maybe because the regex is not transformed to an equality because of a collate -related change in pg18

[m3hm3t]

maybe move test to pg18 or add alternative output

[m3hm3t]

maybe reason

"An asynchronous I/O (AIO) subsystem that can improve performance of sequential scans, bitmap heap scans, vacuums, and other operations."

https://www.postgresql.org/docs/release/18.0/?utm_source=chatgpt.com#:~:text=An%20asynchronous%20I/O%20(AIO)%20subsystem%20that%20can%20improve%20performance%20of%20sequential%20scans%2C%20bitmap%20heap%20scans%2C%20vacuums%2C%20and%20other%20operations.

[colm-mchugh]

Describe table (\d) has not changed implementation in PG18 - specifically SQL emitted by C function processSQLNamePattern(). It would be useful to understand why in PG18 the COLLATE sub-clause influences the plan change to prefer a sequential scan over an index scan. An alternative goldfile for PG18 is reasonable, so let's go with that?