From: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> |
---|---|
To: | Greg Nancarrow <gregn4422(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, "Amit Langote" <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "Tang, Haiying" <tanghy(dot)fnst(at)cn(dot)fujitsu(dot)com> |
Subject: | RE: Parallel INSERT (INTO ... SELECT ...) |
Date: | 2021-02-02 08:26:49 |
Message-ID: | 1535a76acefb4902b719e2a32b7cf7b0@G08CNEXMBPEKD05.g08.fujitsu.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> I've had a further look at this, and this walker function is doing a lot
> of work recursing the parse tree, and I'm not sure that it reliably retrieves
> the information that we;re looking for, for all cases of different SQL
> queries. Unless it can be made much more efficient and specific to our needs,
> I think we should not try to do this optimization, because there's too much
> overhead. Also, keep in mind that for the current parallel SELECT
> functionality in Postgres, I don't see any similar optimization being
> attempted (and such optimization should be attempted at the SELECT level).
> So I don't think we should be attempting such optimization in this patch
> (but could be attempted in a separate patch, just related to current parallel
> SELECT functionality).
Yes, I agreed,
I was worried about the overhead it may bring too,
we can remove this from the current patch.
Best regards,
houzj
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Lepikhov | 2021-02-02 08:28:27 | Re: [POC] Fast COPY FROM command for the table with foreign partitions |
Previous Message | Fujii Masao | 2021-02-02 08:18:53 | Re: Transactions involving multiple postgres foreign servers, take 2 |