RE: Parallel INSERT (INTO ... SELECT ...)

From: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
To: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Parallel INSERT (INTO ... SELECT ...)
Date: 2021-01-19 06:57:58
Message-ID: TYAPR01MB2990B50069E85D93ADFE794BFEA30@TYAPR01MB2990.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> Tsunakawa-San, does this address your concerns around locking the
> target relation in the required cases? It would be good to test but I
> don't see any problems in the scenarios you mentioned.

Thank you, understood. RevalidateCachedQuery() does parse analysis, that's the trick.

Regards
Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2021-01-19 07:41:20 Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
Previous Message Corey Huinker 2021-01-19 06:56:26 Re: Release SPI plans for referential integrity with DISCARD ALL