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 1fWNWK-0006rR-7e for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jun 2018 14:58:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fWNWG-0005xz-7v for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jun 2018 14:58:36 +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 1fWNWF-0005xr-VK for pgsql-hackers@lists.postgresql.org; Fri, 22 Jun 2018 14:58:36 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fWNWC-0001rg-1l for pgsql-hackers@postgresql.org; Fri, 22 Jun 2018 14:58:34 +0000 Received: by mail-lj1-x236.google.com with SMTP id v15-v6so1354668ljk.5 for ; Fri, 22 Jun 2018 07:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZKwveheQKf4cK9bUR3QKNK+ImlzyLc/Do0FXgMXUDZI=; b=QjfcgZXoQ4iPefoqB6kXwXBvkyaCsnar5ShmVTvYo62x3g324ICzRZRq8UhikV+Qa0 ItiovBhI6hESa/3vU+Oj1qcL9RMJnbh2xNkKaJO81P++YHIdN4XJc2lp94/JCAadcoP6 vb4+KxN6+d5gvdIlA0beToVfwYKDgxZQ/bWZ+ZKbalVRk6tBzfna0CBkliHie8yIWR0Q epBaKG4hnNElStfMy+/mIZ652I6hRbn3doq/VRBtyMnKQLSot381sHF9ZGWUonmCFPCa jnDrF642drLHjeGEXOahmThILzSJsbau6P/I6Xu1DqMjHns5xMz5DMnkLRFE29j4kYkv j09w== 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=ZKwveheQKf4cK9bUR3QKNK+ImlzyLc/Do0FXgMXUDZI=; b=WTXIB+H3rCdfI5FXBbn30t29DILf0CQqNohLQ2/1Nrq4EtKw+YG6EWF7BSTU39hBgj TN/kZsj9XphX03pxv2wHxeL66KYmgTX4bO992zcZHZoGy8GHsRkaYkwOmx4t382iu6ln Wla/EOGDQI6/jQja/eFPAI7UwLswm8DkxC2DDlmA/y6Fal6lWh37KpG3BKjzGmRB6A0n 0rSy8oO7PgG+1qZrhmKb1ectiVHqOX/CUmjy/ofKy8M8gZfEABBrsbpx80QWY34nbiEQ zzChSalmCSMhDycUEhlrdF6mKvBqR7+JGFO5MQvXQj4wRx/tisVzAQgJm0hbQ97ctTW9 YKqQ== X-Gm-Message-State: APt69E2rAUN2W7IUwdu72UTO4/wG0+8VZ7/KbY/YVMtB2x6u4tSSQexZ hTiCavRT/YJs5L6ntI+ZXw8QK0G8dhJiCPdMpxY= X-Google-Smtp-Source: ADUXVKIQZCr/SnG5wzaCRRMVm6i+Fty1Yc14db0gG58cauDyUfPo5InKEzh+utqtCKUi0Mp6EFSUlFmQxUOBxeCOti0= X-Received: by 2002:a2e:2161:: with SMTP id h94-v6mr1536445ljh.58.1529679509411; Fri, 22 Jun 2018 07:58:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:ea43:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 07:58:28 -0700 (PDT) In-Reply-To: <5B28FB19.3090809@lab.ntt.co.jp> References: <5AE84FBF.3040905@lab.ntt.co.jp> <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> From: Robert Haas Date: Fri, 22 Jun 2018 10:58:28 -0400 Message-ID: Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. To: Etsuro Fujita Cc: Ashutosh Bapat , 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 Tue, Jun 19, 2018 at 8:46 AM, Etsuro Fujita wrote: > Here is a patch for that. > > * As I said upthread, the patch makes code much more simple; I removed all > the changes to setrefs.c added by the partitionwise-join patch. I also > simplified the logic for building a tlist for a child-join rel. The original > PWJ computes attr_needed data even for child rels, and build the tlist for a > child-join by passing to build_joinrel_tlist that data for input child rels > for the child-join. But I think that's redundant, and it's more > straightforward to apply adjust_appendrel_attrs to the parent-join's tlist > to get the child-join's tlist. So, I changed that way, which made > unnecessary all the changes to build_joinrel_tlist and placeholder.c added > by the PWJ patch, so I removed those as well. > > * The patch contains all of the regression tests in the original patch > proposed by Ashutosh. I think this approach is going to run into trouble if the level at which we have to apply the ConvertRowTypeExpr happens not to be a projection-capable node. 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. We certainly don't want it to happen at the Append level, which can't even handle it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company