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 по дате отправления:

Предыдущее
От: Thomas Butz
Дата:
Сообщение: Re: BUG #16241: Degraded hash join performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16241: Degraded hash join performance