On Thu, Jun 21, 2018 at 07:42:54AM +0530, Amit Kapila wrote:
> On Wed, Jun 20, 2018 at 8:47 PM, Bruce Momjian <br...@momjian.us> wrote:
> > On Sat, Jun 2, 2018 at 05:18:17PM -0400, Asim Praveen wrote:
> >> Hi Amit
> >>
> >> On Mon, May 28, 2018 at 4:25 AM, Amit Kapila <amit.kapil...@gmail.com>
> >> wrote:
> >> >
> >> > This is one way, but I think there are other choices as well. We can
> >> > identify and flush all the dirty (local) buffers for the relation
> >> > being accessed parallelly. Now, once the parallel operation is
> >> > started, we won't allow performing any write operation on them. It
> >>
> >> We talked about this in person in Ottawa and it was great meeting you!
> >> To summarize, the above proposal to continue using local buffers for
> >> temp tables is a step forward, however, it enables only certain kinds
> >> of queries to be parallelized for temp tables. E.g. queries changing
> >> a temp table in any way cannot be parallelized due to the restriction
> >> of no writes during parallel operation.
> >
> > Should this be a TODO item?
> >
>
> +1. I think we have not hammered out the design completely, but if
> somebody is willing to put effort, it is not an unsolvable problem.
> AFAIU, this thread is about parallelizing queries that refer temp
> tables, however, it is not clear from the title of this thread.
Seems it is already documented on the wiki:
https://wiki.postgresql.org/wiki/Parallel_Query#What_Parts_of_a_Query_Can_Run_In_Parallel.3F
o Scans of plain tables may not appear below Gather if (1) they are
temporary tables ...
----------------
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
