On Wed, Jul 19, 2017 at 7:45 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, Jul 20, 2017 at 7:00 AM, Robert Haas <robertmh...@gmail.com> wrote: >> I think the problem is that the row count estimates for the child >> joins seem to be totally bogus: >> >> -> Hash Semi Join (cost=309300.53..491665.60 rows=1 width=12) >> (actual time=10484.422..15945.851 rows=1523493 loops=3) >> Hash Cond: (l1.l_orderkey = l2.l_orderkey) >> Join Filter: (l2.l_suppkey <> l1.l_suppkey) >> Rows Removed by Join Filter: 395116 >> >> That's clearly wrong. In the un-partitioned plan, the join to l2 >> produces about as many rows of output as the number of rows that were >> input (998433 vs. 962909); but here, a child join with a million rows >> as input is estimated to produce only 1 row of output. I bet the >> problem is that the child-join's row count estimate isn't getting >> initialized at all, but then something is clamping it to 1 row instead >> of 0. >> >> So this looks like a bug in Ashutosh's patch. > > Isn't this the same as the issue reported here? > > https://www.postgresql.org/message-id/flat/CAEepm%3D270ze2hVxWkJw-5eKzc3AB4C9KpH3L2kih75R5pdSogg%40mail.gmail.com
Hmm, possibly. But why would that affect the partition-wise join case only? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
