| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, ilmari(at)ilmari(dot)org |
| Subject: | Re: Expand applicability of aggregate's sortop optimization |
| Date: | 2024-09-03 06:25:53 |
| Message-ID: | fd025d80-568a-49e2-b286-f757e6533f39@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18/7/2024 14:49, Matthias van de Meent wrote:
> Aside: Arguably, checking for commutator operators would not be
> incorrect when looking at it from "applied operators" point of view,
> but if that commutative operator isn't registered as opposite ordering
> of the same btree opclass, then we'd probably break some assumptions
> of some aggregate's sortop - it could be registered with another
> opclass, and that could cause us to select a different btree opclass
> (thus: ordering) than is indicated to be required by the aggregate;
> the thing we're trying to protect against here.
Hi,
This thread stands idle. At the same time, the general idea of this
patch and the idea of utilising prosupport functions look promising. Are
you going to develop this feature further?
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-09-03 06:27:37 | Re: define PG_REPLSLOT_DIR |
| Previous Message | Thomas Munro | 2024-09-03 06:21:59 | Re: v17 vs v16 performance comparison |