Re: support create index on virtual generated column.
Soumya S Murali <soumyamurali.work@gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-27T10:45:33Z
Lists: pgsql-hackers
Attachments
- 0001-skip-virtual-generated-column-handling-during-bootst.patch (text/x-patch) patch 0001
Hi all, On Thu, Feb 19, 2026 at 5:18 PM jian he <jian.universality@gmail.com> wrote: > > On Thu, Jul 31, 2025 at 2:24 AM Corey Huinker <corey.huinker@gmail.com> wrote: > > > >> > >> Besides, this does nothing you haven't been able to do for > >> decades with expression indexes. > > > > > > What I'm hoping for with this feature is a smoother transition when people start introducing virtual columns. If there was already an index on that expression, and some queries start using the new virtual column (with the same expression), will that cause those queries to miss the index we already have? If it doesn't, then a customer can roll out the query changes at will and not need to do some cut-over from using the expression to using the virtual column. > > > > hi. > I am not sure whether this concern has been addressed, as I am still somewhat > confused by the above paragraph. > > As noted earlier, creating an index on a virtual generated column results in a > new index, and that index behaves the same as a regular expression index. > > An updated and polished patch is attached. The regress tests are quite verbose > at the moment, since I make it covered all index types (btree, gist, spgist, > hash, gin, and brin). > I went through the discussions and have reviewed the patch. During testing, I encountered a segmentation fault during initdb which occurred due to a crash in bootstrap mode when ComputeIndexAttrs() was invoked with pstate == NULL while system catalog indexes were being created. The virtual generated column handling logic was executing unconditionally, which is unsafe during bootstrap because catalog and syscache state are not fully initialized. I fixed this by guarding the virtual generated column logic to skip the logic when IsBootstrapProcessingMode() is true so that it can prevent the generated-column rewrite from executing during bootstrap. After the fix, initdb no longer crashes in bootstrap mode, the full regression test suite passes cleanly, the server starts normally and key behaviors like index creation on virtual generated columns, planner rewrite, dependency tracking, partitioned table support, and dump/restore roundtrips are all correct. Also I performed some additional validations to ensure consistent behaviours. With the bootstrap guard in place, the patch seems functionally correct, catalog-safe, and dump/restore safe. Kindly review the patch. Looking forward to more feedback. Regards, Soumya
Commits
-
Virtual generated columns
- 83ea6c54025b 18.0 cited