public inbox for [email protected]  
help / color / mirror / Atom feed
From: Etsuro Fujita <[email protected]>
To: Robert Haas <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: Rajkumar Raghuwanshi <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.
Date: Wed, 04 Jul 2018 19:06:43 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com>
	<CAFjFpRdSvXxOkSMc=jEHfTVGnCFgziLA7m+onp=ak=Tfa_V1zA@mail.gmail.com>
	<[email protected]>
	<CAFjFpRcFucgvrzEFNi10g00-va640poSmJDmBrZNfFarB6eP-Q@mail.gmail.com>
	<[email protected]>
	<CAFjFpRczEuG9b0_j_qve2JAi-HHqS9_m1_yK5QVQa5=oDr5mJA@mail.gmail.com>
	<[email protected]>
	<CAFjFpRfkafBFJSEEkGwzLf=-y9Q8TUEGfpR=+K7-zCOw80R10w@mail.gmail.com>
	<CAFjFpRc8ZoDm0+zhx+MckwGyEqkOzWcpVqbvjaxwdGarZSNrmA@mail.gmail.com>
	<[email protected]>
	<CAFjFpRfGL9w-4C5N-ioaG3m+iheC1ey7_RMZ4vJijGn=wWJyxw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFjFpRffA-BfL0RXcUVLLbcOBF1ie7oObTB-RE2q_o45X1HTYg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected] om>
	<[email protected] p>

(2018/07/02 18:46), Etsuro Fujita wrote:
> (2018/06/22 23:58), Robert Haas wrote:
>> And, in general, it seems to me that we want
>> to produce the right outputs at the lowest possible level of the plan
>> tree. For instance, suppose that one of the relations being scanned
>> is not parallel-safe but the others are. Then, we could end up with a
>> plan like this:
>>
>> Append
>> -> Seq Scan on temp_rela
>> -> Gather
>> -> Parallel Seq Scan on thing1
>> -> Gather
>> -> Parallel Seq Scan on thing2
>>
>> If a projection is required to convert the row type expression, we
>> certainly want that to get pushed below the Gather, not to happen at
>> the Gather level itself.
>
> IIUC, we currently don't consider such a plan for partition-wise join;
> we'll only consider gathering partial paths for the parent appendrel.

While updating the patch, I noticed that I'm wrong here.  IIUC, 
apply_scanjoin_target_to_paths would allow us to consider such an Append 
for a partitioned relation when scanjoin_target_parallel_safe=false, as 
it generates new Append paths by recursively adjusting all partitions 
for which we call generate_gather_paths in that case as shown below:

     /*
      * If the scan/join target is not parallel-safe, partial paths cannot
      * generate it.
      */
     if (!scanjoin_target_parallel_safe)
     {
         /*
          * Since we can't generate the final scan/join target, this is our
          * last opportunity to use any partial paths that exist.  We 
don't do
          * this if the case where the target is parallel-safe, since we 
will
          * be able to generate superior paths by doing it after the final
          * scan/join target has been applied.
          *
          * Note that this may invalidate rel->cheapest_total_path, so 
we must
          * not rely on it after this point without first calling 
set_cheapest.
          */
         generate_gather_paths(root, rel, false);

         /* Can't use parallel query above this level. */
         rel->partial_pathlist = NIL;
         rel->consider_parallel = false;
     }

I don't produce a test case where the plan is an Append with Gather 
subplans, but I'm not sure that it's a good thing to allow us to 
consider such a plan because in that plan, each Gather would try to grab 
its own pool of workers.  Am I missing something?

Best regards,
Etsuro Fujita




view thread (115+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox