| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Thomas Butz <tbutz(at)optitool(dot)de> |
| Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16241: Degraded hash join performance |
| Date: | 2020-02-04 15:01:52 |
| Message-ID: | 20200204150152.prebesyfo2idnyum@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2020-02-04 15:49:10 +0100, Thomas Butz wrote:
> I was able to reduce it to a minimal example:
>
> SELECT localized_streetname
> FROM planet_osm_line
> WHERE "way" && ST_SetSRID('BOX3D(1222380.956336539 6339381.37785938,1233387.888409604 6350388.309932444)'::box3d, 3857)
>
> Your diagnosis with osml10n_get_streetname_from_tags was spot on. I'm going to report it to the author of the osml10n extension.
Cool. Still worth checking whether there's a 11 vs 12 issue inside that function.
> Thank you for your help!
>
> PS: I've created the execution plans using EXPLAIN (ANALYZE, VERBOSE, COSTS, BUFFERS, TIMING, SUMMARY, FORMAT json) but i wasn't aware that i might have to check the "Output" section of a node to find potential performance problems. How do you find such slow outputs without using perf?
It's not trivial, unfortunately :(. You can use track_functions to get
more insight, but that's better for server-wide analysis, than query
specific ones. auto_explain also has options to track nested queries,
which might help as well.
I hope we can extend EXPLAIN with more information about this kind of
thing at some point.
Regards,
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-02-04 16:00:29 | Re: BUG #16241: Degraded hash join performance |
| Previous Message | Thomas Butz | 2020-02-04 14:49:10 | Re: BUG #16241: Degraded hash join performance |