Re: Trying to understand why a query is filtering when there is a composite index

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: "Stephen Samuel (Sam)" <sam(at)sksamuel(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Trying to understand why a query is filtering when there is a composite index
Date: 2024-08-19 02:08:24
Message-ID: CAH2-WzkX7BZYqBTyLPNZxkkM8ovX28N-Pc+-RYM877HZY48NnQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, Aug 18, 2024 at 10:01 PM Stephen Samuel (Sam) <sam(at)sksamuel(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stephen Samuel (Sam) 2024-08-19 02:09:51 Re: Trying to understand why a query is filtering when there is a composite index
Previous Message Stephen Samuel (Sam) 2024-08-19 02:01:16 Re: Trying to understand why a query is filtering when there is a composite index