Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1+9OqD16v6mQnmMRQ5adsLb_EbJAk0BmrcRMKaGXpyBDg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jan 22, 2015 at 10:30 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jan 22, 2015 at 6:37 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >
> > (Please point out me if my understanding is incorrect.)
> >
> > What happen if dynamic background worker process tries to reference temporary
> > tables? Because buffer of temporary table blocks are allocated on private
> > address space, its recent status is not visible to other process unless it is
> > not flushed to the storage every time.
> >
> > Do we need to prohibit create_parallelscan_paths() to generate a path when
> > target relation is temporary one?
> >
>
> Yes, we need to prohibit parallel scans on temporary relations.  Will fix.
>

Here is the latest patch which fixes reported issues and supported
Prepared Statements and Explain Statement for parallel sequential
scan.

The main purpose is to get the feedback if possible on overall
structure/design of code before I goahead.

Note - 
a. it is still based on parallel-mode-v1 [1] patch of Robert. 
b. based on CommitId - fd496129 [on top of this commit, apply
    Robert's patch and then the attached patch]
c. just build and tested on Windows, my linux box has some
problem, will fix that soon and verify this on linux as well.

[1]

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: "Syed, Rahila"
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Next
From: Thom Brown
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0