Re: using memoize in in paralel query decreases performance - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: using memoize in in paralel query decreases performance
Date
Msg-id CAFj8pRBRvK2_EGeD7J_37ncax0x7Q==C=zTpg2WzM0uWnvaixg@mail.gmail.com
Whole thread Raw
In response to Re: using memoize in in paralel query decreases performance  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: using memoize in in paralel query decreases performance  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers


po 6. 3. 2023 v 9:16 odesílatel David Rowley <dgrowleyml@gmail.com> napsal:
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?

15.1 - upgrade on 15.2 is planned this month
 

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 by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Combine pg_walinspect till_end_of_wal functions with others
Next
From: Daniel Gustafsson
Date:
Subject: Re: Allow tests to pass in OpenSSL FIPS mode