From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: support fast default for domain with constraints |
Date: | 2025-03-06 13:53:40 |
Message-ID: | CACJufxECb4nVjssRPknepNmqF2CR0ycPzTmJZPxoWYK4JD-mFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 6, 2025 at 11:04 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> hi.
>
> rearrange the patch.
> v3-0001 and v3-0002 is preparare patches.
> v3-0001 add function: ExecPrepareExprSafe and ExecInitExprSafe.
> v3-0002 add function: DomainHaveVolatileConstraints
>
i actually do need DomainHaveVolatileConstraints
for virtual generated columns over domain with constraints in [1],
which I am working on.
for example:
create domain d1 as int check(value > random(min=>11::int, max=>12));
create domain d2 as int check(value > 12);
create table t(a int);
insert into t select g from generate_series(1, 10) g;
----we do need table rewrite in phase 3.
alter table t add column b d1 generated always as (a+11) virtual;
--we can only do table scan in phase 3.
alter table t add column c d2 generated always as (a + 12) virtual;
Generally, table rewrite is more expensive than table scan.
In the above case, if domain constraints are not volatile, table scan
should be fine.
[1]: https://postgr.es/m/CACJufxHArQysbDkWFmvK+D1TPHQWWTxWN15cMuUaTYX3xhQXgg@mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2025-03-06 13:57:01 | Re: dblink query interruptibility |
Previous Message | Andrew Dunstan | 2025-03-06 13:51:02 | Re: jsonb_strip_nulls with arrays? |