Horton

Re: Postgres: Queries are too slow after upgrading to PG17 from PG15

Peter Geoghegan <pg@bowt.ie>

View thread
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Sajith Prabhakar Shetty <ssajith@blackduck.com>, Andrei Lepikhov <lepihov@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, Todd Cook <cookt@blackduck.com>
Date: 2025-07-31T21:40:51Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Convert strategies to and from compare types

  2. Enhance nbtree ScalarArrayOp execution.

  3. Improve planning of btree index scans using ScalarArrayOpExpr quals.

  4. Fix planning of btree index scans using ScalarArrayOpExpr quals.

On Thu, Jul 31, 2025 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Cool, will you do the legwork?

I'll give it a go.

> > Is there a convenient choke point for this in the planner?
>
> I'd be inclined to do it as late as possible, in create_plan
> (so that we don't expend the effort if we don't choose that
> index path).  So in or near fix_indexqual_references is
> probably a good spot.

Understood.

> >> An alternative thought is that maybe the run-time sort is expensive
> >> enough that the planner ought to account for it in its estimates.
>
> > I tend to doubt that this will ever make much sense.
>
> As you say, getting the cost estimates accurate enough is daunting,
> which is why I called it a research project.

I think that it might make sense to add a little more startup cost to
plans with SAOP arrays. But that doesn't seem likely to help with this
particular problem.

-- 
Peter Geoghegan