| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Partition-wise join for join between (declaratively) partitioned tables |
| Date: | 2017-07-19 23:45:57 |
| Message-ID: | CAEepm=2h0Xo=_5e3vDyXLE-rsCpC1A=7DcF_w1Xz1bPJGXmPBg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 20, 2017 at 7:00 AM, Robert Haas <robertmhaas(at)gmail(dot)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?
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2017-07-20 00:54:38 | psql's \r broken since e984ef5861d |
| Previous Message | Stephen Frost | 2017-07-19 23:24:35 | Re: autovacuum can't keep up, bloat just continues to rise |