On Mon, 2 May 2022 at 11:00, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > Hi > > I found a query that is significantly slower with more memory
Which PostgreSQL version did you use? Did you enable assert checking? Do you have an example database setup to work with? > plan 2 > QUERY PLAN > ---------------- > Nested Loop Anti Join (cost=46.53..2914.58 rows=1 width=16) (actual > time=18.306..23.065 rows=32 loops=1) > ... > Execution Time: 451.161 ms Truly strange; especially the 418ms difference between execution time and the root node's "actual time". I haven't really seen such differences happen, except when concurrent locks were held at the table / index level. > plan 1 - fast https://explain.depesz.com/s/XM1f > > plan 2 - slow https://explain.depesz.com/s/2rBw > > Strange - the time of last row is +/- same, but execution time is 10x worse The only difference between the two plans that I see is that plan 1 doesn't use memoization, whereas plan 2 does use 2 memoize plan nodes (one of 66 misses; one of 342 misses). The only "expensive" operation that I see in memoize nodes is the check for memory size in assert-enabled builds; and that should have very low overhead considering that the size of the memoized data is only 8kB and 25kB respectively.
