Message-ID: <31635fee-f260-49a4-81d3-8f684efdabd3@gmail.com>
Date: Thu, 20 Mar 2025 20:50:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18854: PostgreSQL chooses a suboptimal execution plan when
 using a specific WHERE filter
To: Yoni Sade <yonisade83@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <18854-f5bc660117569bdf@postgresql.org>
 <91d297ae-71ca-4406-a404-f8daa0b0c4a5@gmail.com>
 <CA+82DrV6g=R8VE_HT6jYSJEmCBsik1cPvzL62fK5h9WKXrz=nw@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CA+82DrV6g=R8VE_HT6jYSJEmCBsik1cPvzL62fK5h9WKXrz=nw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/31635fee-f260-49a4-81d3-8f684efdabd3%40gmail.com>
Precedence: bulk

On 19/3/2025 14:34, Yoni Sade wrote:
> I would like to add that commenting out that WHERE clause doesn't work 
> for all of this query variations so I've found another workaround for 
> now ("LIMIT 1000000" in *bold*)
> 
> to make the optimizer better estimate the cardinality of the subquery 
> and change the plan to a better one:*
I wouldn't say it is the ultimate root of the problem, but using 
generate_series, especially with non-constant parameters, seems harmful 
for the query planning: we can't predict the number of tuples and don't 
have any statistics on that set. So, your LIMIT works like a hint that 
helps decide how massive a set of tuples it will generate and seems to 
be the only option possible.

-- 
regards, Andrei Lepikhov