Re: Parallel Seq Scan

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Jeff Davis <pgsql(at)j-davis(dot)com>, "Andres Freund" <andres(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, "Amit Langote" <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Haribabu Kommi" <kommi(dot)haribabu(at)gmail(dot)com>
Subject: Re: Parallel Seq Scan
Date: 2015-08-02 02:36:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Let me ask three more detailed questions.

Why Funnel has a valid qual of the subplan?
The 2nd argument of make_funnel() is qualifier of the subplan
(PartialSeqScan) then it is initialized at ExecInitFunnel,
but never executed on the run-time. Why does Funnel node has
useless qualifier expression here (even though it is harmless)?

Why Funnel delivered from Scan? Even though it constructs
a compatible target-list with underlying partial-scan node,
it does not require the node is also delivered from Scan.
For example, Sort or Append don't change the target-list
definition from its input, also don't have its own qualifier.
It seems to me the definition below is more suitable...
typedef struct Funnel
Plan plan;
int num_workers;
} Funnel;

Does ExecFunnel() need to have a special code path to handle
EvalPlanQual()? Probably, it just calls underlying node in the
local context. ExecScan() of PartialSeqScan will check its
qualifier towards estate->es_epqTuple[].

NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Kouhei Kaigai
> Sent: Thursday, July 30, 2015 8:45 AM
> To: Amit Kapila
> Cc: Robert Haas; Gavin Flower; Jeff Davis; Andres Freund; Amit Langote; Amit
> Langote; Fabrízio Mello; Thom Brown; Stephen Frost; pgsql-hackers; Haribabu Kommi
> Subject: Re: [HACKERS] Parallel Seq Scan
> > On Wed, Jul 29, 2015 at 7:32 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > >
> > > Hi Amit,
> > >
> > > Could you tell me the code intention around ExecInitFunnel()?
> > >
> > > ExecInitFunnel() calls InitFunnel() that opens the relation to be
> > > scanned by the underlying PartialSeqScan and setup ss_ScanTupleSlot
> > > of its scanstate.
> >
> > The main need is for relation descriptor which is then required to set
> > the scan tuple's slot. Basically it is required for tuples flowing from
> > worker which will use the scan tuple slot of FunnelState.
> >
> > > According to the comment of InitFunnel(), it open the relation and
> > > takes appropriate lock on it. However, an equivalent initialization
> > > is also done on InitPartialScanRelation().
> > >
> > > Why does it acquire the relation lock twice?
> > >
> >
> > I think locking twice is not required, it is just that I have used the API
> > ExecOpenScanRelation() which is used during other node's initialisation
> > due to which it lock's twice. I think in general it should be harmless.
> >
> Thanks, I could get reason of the implementation.
> It looks to me this design is not problematic even if Funnel gets capability
> to have multiple sub-plans thus is not associated with a particular relation
> as long as target-list and projection-info are appropriately initialized.
> Best regards,
> --
> NEC Business Creation Division / PG-Strom Project
> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Piotr Stefaniak 2015-08-02 07:59:36 Re: [sqlsmith] Failed assertion in joinrels.c
Previous Message Andrew Dunstan 2015-08-01 23:22:53 Re: upgrade failure from 9.5 to head