From: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs |
Date: | 2020-12-11 01:00:59 |
Message-ID: | 7512c12a009c478cad4365a715a7671b@G08CNEXMBPEKD05.g08.fujitsu.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Currently, for CTAS or CREATE MATERIALIZED VIEW(CMV) without if-not-exists
> clause, the existence of the relation gets checked during the execution
> of the select part and an error is thrown there.
> All the unnecessary rewrite and planning for the select part would have
> happened just to fail later. However, if if-not-exists clause is present,
> then a notice is issued and returned immediately without any further rewrite
> or planning for . This seems somewhat inconsistent to me.
>
> I propose to check the relation existence early in ExecCreateTableAs() as
> well as in ExplainOneUtility() and throw an error in case it exists already
> to avoid unnecessary rewrite, planning and execution of the select part.
>
> Attaching a patch. Note that I have not added any test cases as the existing
> test cases in create_table.sql and matview.sql would cover the code.
>
> Thoughts?
Personally, I think it make sense, as other CMD(such as create extension/index ...) throw that error
before any further operation too.
I am just a little worried about the behavior change of [explain CTAS].
May be someone will complain the change from normal explaininfo to error output.
And I took a look into the patch.
+ StringInfoData emsg;
+
+ initStringInfo(&emsg);
+
+ if (level == NOTICE)
+ appendStringInfo(&emsg,
Using variable emsg and level seems a little complicated to me.
How about just:
if (!is_explain && ctas->if_not_exists)
ereport(NOTICE,xxx
else
ereport(ERROR,xxx
Best regards,
houzj
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-12-11 01:21:19 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | k.jamison@fujitsu.com | 2020-12-11 00:24:45 | RE: [Patch] Optimize dropping of relation buffers using dlist |