| From: | Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: support create index on virtual generated column. |
| Date: | 2026-02-27 10:45:33 |
| Message-ID: | CAMtXxw8_nBrTs2X9UudPnNjhVkJuJ8mQvVP8jqnWCyC3_KbZYA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
On Thu, Feb 19, 2026 at 5:18 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> On Thu, Jul 31, 2025 at 2:24 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-skip-virtual-generated-column-handling-during-bootst.patch | text/x-patch | 1.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2026-02-27 10:48:08 | Re: Portable StaticAssertExpr |
| Previous Message | Alvaro Herrera | 2026-02-27 10:37:31 | Re: pgstat include expansion |