Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1faelD-0006eF-Ag for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jul 2018 10:11:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1faelB-0008CW-JR for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jul 2018 10:11:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1faelB-0008CN-Cc for pgsql-hackers@lists.postgresql.org; Wed, 04 Jul 2018 10:11:41 +0000 Received: from mail-pf0-x233.google.com ([2607:f8b0:400e:c00::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fael8-0006ti-Kf for pgsql-hackers@postgresql.org; Wed, 04 Jul 2018 10:11:40 +0000 Received: by mail-pf0-x233.google.com with SMTP id z24-v6so2434179pfe.7 for ; Wed, 04 Jul 2018 03:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xoGxvYpiRD2eKbGUIgCvh6kbX+BW6EayKlOuJr11sQw=; b=Td5h9Y3R0pGEzoRkBpam2XWx3Ks1zL5wW7HyGJnrQEamDlQdX8eD8wwgLcumJhVK59 11aak/58QJpGldL7rQFL35D2+Zg9XsAqB1nsZgomm6LOHw20RDes3jCuaM0tASCGaTyj 3GDpVu/cXjkaNfK3vC8GB6jNI/3QMHG3mG11Ocx5wgY3w6yElCiAdRkxTOzfc0P+xQgz k5YgGLh4PkK2gemmwYkwBF2p15qyeH8VQhVoiTEk6j/vpfduxZQdwqOiXzKtX/+nxrj2 7zS8MPsDfSHdFtXYFz5PhbbkuN6RGcH04Ta8zcE0um52n9K0gsFXALcQJXeiYiOa5X5q 129Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xoGxvYpiRD2eKbGUIgCvh6kbX+BW6EayKlOuJr11sQw=; b=LTdubcCUQjymJCtvviMzG/UnXazXkIhMBN4zY6CneWHkLmKsIOhBfsE4QgnTXhn9jd S2nN0NG0c1Ed96cApBvdu5c2aKSimEbOEQb32If+rhuVdSSPI3RVWRoDkCVnU98DKsZ4 WaoTZYrEKqMVLymcrkt3Lx+Jtbz1Pi2BNi6HgRiz45121iFfJ2wr1/kPtZvh/rid2u15 SBTaHpdPEFuYitps7Dqtur4eHZjc6bFU1tBAUihET1jPqix29lj3Qq+DqCZpnZc+f4i2 elLSBscf+j5/MegazH3g0cEvBleKa471fRHpYyuXbZWbr5gQFVjXLgyMYlznnx896QAi 5ASQ== X-Gm-Message-State: APt69E2XFkgTZ+jL6Qzwot+rl9dQsj7gi4LumRiwIOrFcHGNKFrs5ofH r4X7jQVPDpN+lx+7lOtHZKTRGvkLEZ/L6pEtIaCxgA== X-Google-Smtp-Source: AAOMgpdycjYQBs5mH0Pt58Lz01BPp9MKCOhnkOonP5d0JUFsH9UWoW+iuis2pfiFPeu32rvNNI8bxXO8QQU/pGAUEQs= X-Received: by 2002:a62:b612:: with SMTP id j18-v6mr1512526pff.199.1530699096455; Wed, 04 Jul 2018 03:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:b43:0:0:0:0 with HTTP; Wed, 4 Jul 2018 03:11:35 -0700 (PDT) In-Reply-To: <5B3C9C33.6030203@lab.ntt.co.jp> References: <5AF2E09F.9060208@lab.ntt.co.jp> <5AF440C2.3040805@lab.ntt.co.jp> <5AF59415.10309@lab.ntt.co.jp> <5AFC0865.8050802@lab.ntt.co.jp> <5AFD6580.5090308@lab.ntt.co.jp> <5AFE81CC.8000508@lab.ntt.co.jp> <5B17C5EC.1090602@lab.ntt.co.jp> <5B1E5071.1000704@lab.ntt.co.jp> <5B23A964.9020800@lab.ntt.co.jp> <5B28FB19.3090809@lab.ntt.co.jp> <5B39F47B.10707@lab.ntt.co.jp> <5B3C9C33.6030203@lab.ntt.co.jp> From: Ashutosh Bapat Date: Wed, 4 Jul 2018 15:41:35 +0530 Message-ID: Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. To: Etsuro Fujita Cc: Robert Haas , Rajkumar Raghuwanshi , pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jul 4, 2018 at 3:36 PM, Etsuro Fujita wrote: > > 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? If the overall join can not use parallelism, having individual child joins use parallel query might turn out to be efficient even if done one child at a time. Parallel append drastically reduces the cases where something like could be useful, but I don't think we can theoretically eliminate the need for such a plan. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company