Re: strange slow query - lost lot of time somewhere
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-05-02T21:48:24Z
Lists: pgsql-hackers
On Mon, 2 May 2022 at 21:00, Pavel Stehule <pavel.stehule@gmail.com> wrote: > I found a query that is significantly slower with more memory Can you clarify what you mean here? More memory was installed on the machine? or work_mem was increased? or? > plan 1 - fast https://explain.depesz.com/s/XM1f > > plan 2 - slow https://explain.depesz.com/s/2rBw If it was work_mem you increased, it seems strange that the plan would switch over to using a Nested Loop / Memoize plan. Only 91 rows are estimated on the outer side of the join. It's hard to imagine that work_mem was so low that the Memoize costing code thought there would ever be cache evictions. > Strange - the time of last row is +/- same, but execution time is 10x worse > > It looks like slow environment cleaning Can you also show EXPLAIN for the Memoize plan without ANALYZE? Does the slowness present every time that plan is executed? Can you show the EXPLAIN ANALYZE of the nested loop plan with enable_memoize = off? You may ned to disable hash and merge join. David
Commits
-
Correct Memoize's estimated cache hit ratio calculation
- f48b4f892f76 16.0 landed
-
Fix incorrect row estimates used for Memoize costing
- 23c2b76a8322 14.4 landed
- 1e731ed12aac 15.0 landed
-
Allow Memoize to operate in binary comparison mode
- 6c32c0977783 14.2 cited