Re: Trying to understand why a query is filtering when there is a composite index - Mailing list pgsql-performance

From Peter Geoghegan
Subject Re: Trying to understand why a query is filtering when there is a composite index
Date
Msg-id CAH2-WzkX7BZYqBTyLPNZxkkM8ovX28N-Pc+-RYM877HZY48NnQ@mail.gmail.com
Whole thread Raw
In response to Re: Trying to understand why a query is filtering when there is a composite index  ("Stephen Samuel (Sam)" <sam@sksamuel.com>)
Responses Re: Trying to understand why a query is filtering when there is a composite index
List pgsql-performance
On Sun, Aug 18, 2024 at 10:01 PM Stephen Samuel (Sam) <sam@sksamuel.com> wrote:
> Oh as simple as upgrading!
> Ok great, appreciate the quick reply. Will have to wait for AWS to support 17 :)

It is possible to use index quals for both a and b on earlier
versions, with certain restrictions. You might try setting
random_page_cost to a much lower value, to see if that allows the
planner to use such a plan with your real query.

In my experience it's very unlikely that the planner will do that,
though, even when coaxed. At least when there are this many IN()
constants. So you probably really will need to upgrade to 17.

--
Peter Geoghegan



pgsql-performance by date:

Previous
From: "Stephen Samuel (Sam)"
Date:
Subject: Re: Trying to understand why a query is filtering when there is a composite index
Next
From: "Stephen Samuel (Sam)"
Date:
Subject: Re: Trying to understand why a query is filtering when there is a composite index