From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Subject: | Re: Add proper planner support for ORDER BY / DISTINCT aggregates |
Date: | 2022-11-08 08:43:57 |
Message-ID: | 5773143.MhkbZ0Pkbq@aivenlaptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le mardi 8 novembre 2022, 02:31:12 CET David Rowley a écrit :
> 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.
>
> 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
regressions, and having this overcharged just made us miss a new optimization
without changing existing plans. With ordered aggregates, the balance is a bit
trickier and we are at risk of either regressing on aggregate plans, or more
common ordered ones.
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-11-08 08:45:40 | Re: Suppressing useless wakeups in walreceiver |
Previous Message | Peter Eisentraut | 2022-11-08 08:40:20 | Re: libpq support for NegotiateProtocolVersion |