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 1fpgWm-0005px-IF for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Aug 2018 21:06:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fpgWk-0003Ur-9O for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Aug 2018 21:06:54 +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 1fpgWk-0003Uk-2O for pgsql-hackers@lists.postgresql.org; Tue, 14 Aug 2018 21:06:54 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fpgWg-0007fH-Oe for pgsql-hackers@postgresql.org; Tue, 14 Aug 2018 21:06:53 +0000 Received: from [104.156.75.42] (helo=[10.50.12.76]) by meldrar.postgresql.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fpgWY-0008WG-3x; Tue, 14 Aug 2018 21:06:45 +0000 From: "Jonathan S. Katz" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4FF3212C-DB21-4DF3-BE0B-99249B31574C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. Date: Tue, 14 Aug 2018 17:06:31 -0400 In-Reply-To: Cc: Etsuro Fujita , Tom Lane , Andres Freund , Ashutosh Bapat , Rajkumar Raghuwanshi , pgsql-hackers , Alvaro Herrera To: Robert Haas References: <5AFC0865.8050802@lab.ntt.co.jp> <20180703163519.tsigyic5xefunv74@alap3.anarazel.de> <5B3C2A4E.5030901@lab.ntt.co.jp> <5B4F2BE9.3000304@lab.ntt.co.jp> <5B55886F.5090906@lab.ntt.co.jp> <5B5712C8.9030404@lab.ntt.co.jp> <5B59BA55.30200@lab.ntt.co.jp> <5B619D23.4010000@lab.ntt.co.jp> <5358.1533241519@sss.pgh.pa.us> <5B64562A.9000404@lab.ntt.co.jp> <5B645868.6030609@lab.ntt.co.jp> <5B683F60.2070806@lab.ntt.co.jp> <5B717A7B.4010308@lab.ntt.co.jp> X-Mailer: Apple Mail (2.3273) X-Host-Lookup-Failed: Reverse DNS lookup failed for 104.156.75.42 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail=_4FF3212C-DB21-4DF3-BE0B-99249B31574C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 14, 2018, at 11:51 AM, Robert Haas = wrote: >=20 > On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita > wrote: >> One thing I noticed might be an improvement is to skip >> build_joinrel_partition_info if the given joinrel will be to have >> consider_partitionwise_join=3Dfalse; in the previous patch, that = function >> created the joinrel's partition info such as part_scheme and = part_rels if >> the joinrel is considered as partitioned, independently of the flag >> consider_partitionwise_join for it, but if that flag is false, we = don't >> generate PWJ paths for the joinrel, so we would not need to create = that >> partition info at all. This would not only avoid unnecessary = processing in >> that function, but also make unnecessary the changes I made to >> try_partitionwise_join, generate_partitionwise_join_paths, >> apply_scanjoin_target_to_paths, and create_ordinary_grouping_paths. = So I >> updated the patch that way. Please find attached an updated version = of the >> patch. >=20 > I guess the question is whether there are (or might be in the future) > other dependencies on part_scheme. For example, it looks like > partition pruning uses it. I'm not sure whether partition pruning > supports a plan like: >=20 > Append > -> Nested Loop > -> Seq Scan on p1 > -> Index Scan on q1 > >=20 > If it doesn't, that's just an implementation restriction; somebody > might want to fix things so it works, if it doesn't already. While we (the RMT) are happy to see there has been progress on this = thread, 11 Beta 3 was released containing this problem and the time to = adequately test this feature prior to GA release is rapidly dwindling. The RMT would like to see this prioritized and resolved. At this point = we have considered the option of having partitionwise joins completely disabled = in PostgreSQL 11. This is preferably not the path we want to choose, but = this option is now on the table and we will issue an ultimatum soon if we do = not see further progress. In the previous discussion, the generally accepted solution for = PostgreSQL 11 seemed to be to disable the problematic case and any further work would = be for PostgreSQL 12 only. If something is different, please indicate why ASAP = and work to resolve. The RMT will also conduct some additional technical = analysis as well. Sincerely, Alvaro, Andres, Jonathan --Apple-Mail=_4FF3212C-DB21-4DF3-BE0B-99249B31574C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE+oS2la8r95ogZD/x8QSccp8cZScFAltzRFcACgkQ8QSccp8c ZScpYQ//f4J16z/71xbdlY+wlM5bYqlXT3l6vlf7e5ZrxPtD+1uHrYnaZBtVgEoW GZ/PcXDSRmrh5D4rUF0+y9hYb8/gbP1bunLscT6gNwtZG85kX7cIk54pFqVjuaa5 kxYJZsMQ+B0HwxGrvPC4Ffa745XuxEP2cJUz7apuhBtRlAqG/7sSfi7b5bLWJocw c660h0Tt6euUOZ25i0GMPfwGk/WWTt0sgnlPZEr29K8cPbFEPKLxPToDxoM7yP0D AQD4gn2kR4kHiJR0JIv4SmGva1L4+GcSq43tSntOA8gK+LGRVl4PxsfIIECeL5Pm ig6XgeMbkRfPovl3a7Kg8mfFq5E+5YiRrdNUACNg4iHfhVHNRQ0/CT+ZhIt2UtIh qQYq0SEj+oCGw/NhnJNg1Gsr34p+PF097rODHLM+iSBtH0JVKZMYhFZiP8LSP2FN 4sJErzD3DdA6LhcfG1cAJrEYyQXaaRjO6brj1lEzoqwx8uiAAwB1ZsPHvCoYR7t7 8Afhpp7RzW+8yH3RV8VTevS0axCRoH6dZDSH3Ebg+OFonLSWUuEoFOkHFXmD82hR B8oct4lF5my3AOdQQKFqw6keivS16jaKEirCmqzDsMWcwCS2nh7NyBT4kQVN9IQB 5ZEKgMKMFepFOIwNtMbn7eUOG0nf0h3MV7ymkmEyLC06ImheNzk= =JijV -----END PGP SIGNATURE----- --Apple-Mail=_4FF3212C-DB21-4DF3-BE0B-99249B31574C--