Re: BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT.

On Wed, 21 Jan 2026 at 23:44, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> In the following test case, there are two equivalent simple SELECTs with
> DISTINCT, however, the normal SELECT is slower than the prepared SELECT.
> Given that prepared SELECT statements typically generate suboptimal query
> plans due to the presence of unknown literals, one would expect prepared
> SELECT to be slower than normal SELECT. However, in this example, the
> prepared SELECT executes faster, suggesting that there may still be room for
> optimization in the query plan generation for normal SELECT.

Ultimately, the SeqScan -> NestLoop -> Hash Agg plan is only winning
over the Index Only Scan -> NestLoop -> Unique due to the planner's
estimated costs for the Nested Loop's inner scan. If you find the cost
balance between Seq Scan vs Index [Only] Scan isn't accurate for your
hardware, then adjust random_page_cost.

The planner not choosing the fastest to execute plan all the time does
not constitute a bug. You may want to consult the documentation in
[1]. [2] may also be useful to you.

David

[1] https://www.postgresql.org/docs/18/runtime-config-query.html#GUC-RANDOM-PAGE-COST
[2] https://www.postgresql.org/docs/18/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE