Re: using memoize in in paralel query decreases performance
От | David Rowley |
---|---|
Тема | Re: using memoize in in paralel query decreases performance |
Дата | |
Msg-id | CAApHDvonLQUDc7SUD4Usok=BP4T+5fK7rcM-wVOmtsvqdu1nAA@mail.gmail.com обсуждение исходный текст |
Ответ на | using memoize in in paralel query decreases performance (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: using memoize in in paralel query decreases performance
|
Список | pgsql-hackers |
On Mon, 6 Mar 2023 at 20:34, Pavel Stehule <pavel.stehule@gmail.com> wrote: > In one query I can see very big overhead of memoize node - unfortunately with hits = 0 > > The Estimate is almost very good. See details in attachment Are you able to share the version number for this? Also, it would be good to see EXPLAIN ANALYZE *VERBOSE* for the memorize plan so we can see the timings for the parallel workers. The results of: EXPLAIN ANALYZE SELECT DISTINCT ictc.sub_category_id FROM ixfk_ictc_subcategoryid ictc INNER JOIN item i ON i.item_category_id = ictc.sub_category_id WHERE ictc.super_category_id = ANY ('{47124,49426,49488,47040,47128}'::bigint[]); would also be useful. That should give an idea of the ndistinct estimate. I guess memorize thinks there are fewer unique values than the 112 that were found. There's probably not much to be done about that. The slowness of the parallel workers seems like a more interesting thing to understand. David
В списке pgsql-hackers по дате отправления: