public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Rowley <[email protected]>
To: [email protected]
To: [email protected]
Subject: Re: BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT.
Date: Thu, 22 Jan 2026 14:31:35 +1300
Message-ID: <CAApHDvqoKO7jTDoftvzWd2VBouCsYDHwa690xk8xMXPErs8Oqw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

On Wed, 21 Jan 2026 at 23:44, PG Bug reporting form
<[email protected]> 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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT.
  In-Reply-To: <CAApHDvqoKO7jTDoftvzWd2VBouCsYDHwa690xk8xMXPErs8Oqw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox