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

From: "Stephen Samuel (Sam)" <sam(at)sksamuel(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
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:09:51
Message-ID: CANRyZ7YRbC8LgdGxbUcRuTuaJ7L=7zJsuNK-DaPt13fwn=Df-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)bowt(dot)ie> wrote:

> 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

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2024-08-19 02:50:10 Re: Trying to understand why a query is filtering when there is a composite index
Previous Message Peter Geoghegan 2024-08-19 02:08:24 Re: Trying to understand why a query is filtering when there is a composite index