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

From Stephen Samuel (Sam)
Subject Re: Trying to understand why a query is filtering when there is a composite index
Date
Msg-id CANRyZ7YRbC8LgdGxbUcRuTuaJ7L=7zJsuNK-DaPt13fwn=Df-g@mail.gmail.com
Whole thread Raw
In response to Re: Trying to understand why a query is filtering when there is a composite index  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-performance
Performance is pretty good anyway, and I'm only running 5 r7.large readers on this service, I was just looking at the query planner and it surprised me.


On Sun, 18 Aug 2024 at 21:08, Peter Geoghegan <pg@bowt.ie> wrote:
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: Peter Geoghegan
Date:
Subject: Re: Trying to understand why a query is filtering when there is a composite index
Next
From: Tom Lane
Date:
Subject: Re: Trying to understand why a query is filtering when there is a composite index