Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Andrei Lepikhov <lepihov(at)gmail(dot)com>, Vivek Gadge <vvkgadge56(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6
Date: 2025-09-10 06:20:16
Message-ID: CAApHDvo8+EHLZn-o3TkQsDRn43HOub2dTUSRY0c=xyxvax9_wQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 10 Sept 2025 at 16:26, Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Wed, Sep 10, 2025 at 4:27 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > This seems quite separate from what's being complained about here. It
> > might be beneficial to reconsider whether we should do some sort of
> > sorting on startup_subpaths inside add_paths_to_append_rel(). I
> > imagine that it might make some sense to sort that list so the path
> > with the cheapest startup cost is first, then put the remainder of the
> > list in order of cheapest total cost per tuple. I suspect that would
> > result in Foreign partitions being scanned last...
>
> If there's LIMIT without ORDER BY, we could order the list of subpaths
> by the number of rows in descending order or cost per row in ascending
> order. That way there are more chances of scanning fewer partitions
> quicker.

Wouldn't that amount to favouring scanning some large foreign
partition over a smaller local partition? My interpretation of
Andrei's "Prefer scanning local partitions to foreign ones" statement
is that was what we shouldn't be doing!

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-09-10 06:28:27 Re: allow benign typedef redefinitions (C11)
Previous Message Michael Paquier 2025-09-10 05:33:40 Re: Remove traces of long in dynahash.c