From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
 Pavel Luzanov <p.luzanov@postgrespro.ru>, Tom Lane <tgl@sss.pgh.pa.us>,
 Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@lists.postgresql.org,
 Ranier Vilela <ranier.vf@gmail.com>
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Date: Tue, 08 Nov 2022 09:43:57 +0100
Message-ID: <5773143.MhkbZ0Pkbq@aivenlaptop>
In-Reply-To: 
 <CAApHDvpkbvDEDJPNZrUqCsCLVC57ZY8qrPn8nGpQSrn4RYstZw@mail.gmail.com>
References: <3163474.aeNJFYEL58@aivenronan> <2202180.iZASKD2KPV@aivenlaptop>
 <CAApHDvpkbvDEDJPNZrUqCsCLVC57ZY8qrPn8nGpQSrn4RYstZw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/5773143.MhkbZ0Pkbq%40aivenlaptop>
Precedence: bulk

Le mardi 8 novembre 2022, 02:31:12 CET David Rowley a =E9crit :
> 1. Adjusts add_paths_to_grouping_rel so that we don't add a Sort path
> when we can add an Incremental Sort path instead. This removes quite a
> few redundant lines of code.

This seems sensible

> 2. Removes the * 1.5 fuzz-factor in cost_incremental_sort()
> 3. Does various other code tidy stuff in cost_incremental_sort().
> 4. Removes the test from incremental_sort.sql that was ensuring the
> inferior Sort -> Sort plan was being used instead of the superior Sort
> -> Incremental Sort plan.
>=20
> I'm not really that 100% confident in the removal of the * 1.5 thing.
> I wonder if there's some reason we're not considering that might cause
> a performance regression if we're to remove it.

I'm not sure about it either. It seems to me that we were afraid of=20
regressions, and having this overcharged just made us miss a new optimizati=
on=20
without changing existing plans. With ordered aggregates, the balance is a =
bit=20
trickier and we are at risk of either regressing on aggregate plans, or mor=
e=20
common ordered ones.

=2D-
Ronan Dunklau