From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Tobias Bussmann *EXTERN*" <t(dot)bussmann(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Subject: | Re: Parallel execution and prepared statements |
Date: | 2016-12-06 18:07:58 |
Message-ID: | 21781.1481047678@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Done.
The comment seems quite confused now:
* If a tuple count was supplied or data is being written to relation, we
* must force the plan to run without parallelism, because we might exit
* early.
Exit early is exactly what we *won't* do if writing to an INTO rel, so
I think this will confuse future readers. I think it should be more like
* If a tuple count was supplied, we must force the plan to run without
* parallelism, because we might exit early. Also disable parallelism
* when writing into a relation, because [ uh, why exactly? ]
Considering that the writing would happen at top level of the executor,
and hence in the parent process, it's not actually clear to me why the
second restriction is there at all: can't we write tuples to a rel even
though they came from a parallel worker? In any case, the current wording
of the comment is a complete fail at explaining this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-06 18:36:09 | Re: [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates. |
Previous Message | Tom Lane | 2016-12-06 17:51:36 | Re: Select works only when connected from login postgres |