From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Virtual generated columns |
Date: | 2025-02-18 13:12:31 |
Message-ID: | CAMbWs4_LRNGAxbQbLOrj+VMy80dUR5v2JQ9fVcre10C4KVYUDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 18, 2025 at 7:09 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> It seems to me that, for a relation in the rangetable that has virtual
> generated columns, we can consider it a subquery to some extent. For
> instance, suppose we have a query:
>
> select ... from ... join t on ...;
>
> and suppose t.b is a virtual generated column. We can consider this
> query as:
>
> select ... from ... join (select a, expr() as b from t) as t on ...;
>
> In this sense, I'm wondering if we can leverage the
> pullup_replace_vars architecture to expand the virtual generated
> columns. I believe this would help avoid a lot of duplicate code with
> pullup_replace_vars_callback.
I had a try with this idea, and attached is what I came up with. It
fixes all the mentioned issues but still requires significant
refinement, particularly due to the lack of comments. By leveraging
the pullup_replace_vars architecture to expand the virtual generated
columns, it saves a lot of duplicate code.
Thanks
Richard
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Expand-virtual-generated-columns-in-planner.patch | application/octet-stream | 11.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-02-18 13:25:53 | Re: SIMD optimization for list_sort |
Previous Message | Dagfinn Ilmari Mannsåker | 2025-02-18 13:11:11 | Re: test_escape: invalid option -- 'c' |