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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sajith Prabhakar Shetty <ssajith(at)blackduck(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Todd Cook <cookt(at)blackduck(dot)com>
Subject: Re: Postgres: Queries are too slow after upgrading to PG17 from PG15
Date: 2025-07-31 21:40:51
Message-ID: CAH2-WzmOOBV7wtu3K6R_zO105Qi_BE-2Ki5T9KLsHETP=GQwAA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 31, 2025 at 5:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Todd Cook 2025-07-31 21:59:34 Re: Postgres: Queries are too slow after upgrading to PG17 from PG15
Previous Message Tom Lane 2025-07-31 21:25:28 Re: Postgres: Queries are too slow after upgrading to PG17 from PG15