Horton

Re: strange slow query - lost lot of time somewhere

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-05-05T23:28:15Z
Lists: pgsql-hackers 
On Mon, May 2, 2022 at 10:02 PM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

>
>
> út 3. 5. 2022 v 6:57 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> > there is really something strange (see attached file). Looks so this
>> issue
>> > is much more related to planning time than execution time
>>
>> You sure there's not something taking an exclusive lock on one of these
>> tables every so often?
>>
>
> I am almost sure, I can see this issue only every time when I set a higher
> work mem. I don't see this issue in other cases.
>
>>
>>
What are the values of work_mem and hash_mem_multiplier for the two cases?

David J.

Commits

  1. Correct Memoize's estimated cache hit ratio calculation

  2. Fix incorrect row estimates used for Memoize costing

  3. Allow Memoize to operate in binary comparison mode