| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TPC-H Q20 from 1 hour to 19 hours! |
| Date: | 2017-05-25 04:03:44 |
| Message-ID: | CA+TgmobpEoSz1sYckVCdQhYXJjHujDnyMZ43nEyNzwyx8pX5QQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 6, 2017 at 4:37 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> Which brings me to the slightly suspicious bit. On 9.5, there's no
> difference between GROUP and GROUP+LIKE cases - the estimates are exactly
> the same in both cases. This is true too, but only without the foreign key
> between "partsupp" and "part", i.e. the two non-grouped relations in the
> join. And what's more, the difference (1737 vs. 16) is pretty much exactly
> 100x, which is the estimate for the LIKE condition.
I don't follow this. How does the foreign key between partsupp and
part change the selectivity of LIKE?
> So it kinda seems 9.5 does not apply this condition for semi-joins, while
>>=9.6 does that.
If 9.5 and prior are ignoring some of the quals, that's bad, but I
don't think I understand from your analysis why
7fa93eec4e0c9c3e801e3c51aa4bae3a38aaa218 regressed anything.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | amul sul | 2017-05-25 04:29:00 | Re: [POC] hash partitioning |
| Previous Message | Michael Paquier | 2017-05-25 03:41:12 | Commit fests created for PG11 development |