Re: BUG #16241: Degraded hash join performance
От | Andres Freund |
---|---|
Тема | Re: BUG #16241: Degraded hash join performance |
Дата | |
Msg-id | 20200204150152.prebesyfo2idnyum@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #16241: Degraded hash join performance (Thomas Butz <tbutz@optitool.de>) |
Список | 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) buti wasn't aware that i might have to check the "Output" section of a node to find potential performance problems. How doyou 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
В списке pgsql-bugs по дате отправления: