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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux