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
>
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 |