On 18/7/2024 00:03, David Rowley wrote:
On Wed, 17 Jul 2024 at 17:12, Andrei Lepikhov wrote:
Also, I don't clearly understand the case you mentioned here - does it
mean that you want to nullify orders for other aggregate types if they
are the same as the incoming order?
No, I mean uncondition
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 probabl
On 18/7/2024 19:49, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 16:09, Andrei Lepikhov wrote:
On 17/7/2024 16:33, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
Because the @<@ and @>@ operators are not registered as commutative,
it couldn't apply
On Wed, 17 Jul 2024 at 16:09, Andrei Lepikhov wrote:
>
> On 17/7/2024 16:33, Matthias van de Meent wrote:
> > On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
> >> Thanks for the job! I guess you could be more brave and push down also
> >> FILTER statement.
> >
> > While probably not impossib
On 17/7/2024 16:33, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
As I see, the code:
aggsortop = fetch_agg_sort_op(aggref->aggfnoid);
if (!OidIsValid(aggsortop))
return false;/* not a MIN/MAX aggregate */
used twice and can be evaluated
On Wed, 17 Jul 2024 at 17:12, Andrei Lepikhov wrote:
> I generally like the idea of a support function. But as I can see, the
> can_minmax_aggs() rejects if any of the aggregates don't pass the
> checks. The prosupport feature is designed to be applied to each
> function separately. How do you th
On 17/7/2024 16:33, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
Thanks for the job! I guess you could be more brave and push down also
FILTER statement.
While probably not impossible, I wasn't planning on changing this code
with new optimizations; just ex
On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
>
> On 5/8/24 17:13, Matthias van de Meent wrote:
> > As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are
> > rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT
> > 1; by using the optional sortop field in the
On 5/9/24 08:08, David Rowley wrote:
On Thu, 9 May 2024 at 12:26, David Rowley wrote:
I wonder if we should also consider as an alternative to this to just
have an aggregate support function, similar to
SupportRequestOptimizeWindowClause that just nullifies the aggorder /
aggdistinct fields for
On 5/8/24 17:13, Matthias van de Meent wrote:
As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are
rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT
1; by using the optional sortop field in the aggregator.
However, this optimization is disabled for clauses that
On Thu, 9 May 2024 at 13:08, David Rowley wrote:
> One additional thought is that the above method would also help
> eliminate redundant sorting in queries with a GROUP BY clause.
> Whereas, the can_minmax_aggs optimisation is not applied in that case.
Another argument for using this method is th
On Thu, 9 May 2024 at 12:26, David Rowley wrote:
> I wonder if we should also consider as an alternative to this to just
> have an aggregate support function, similar to
> SupportRequestOptimizeWindowClause that just nullifies the aggorder /
> aggdistinct fields for Min/Max aggregates on types whe
On Wed, 8 May 2024 at 22:13, Matthias van de Meent
wrote:
> As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are
> rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT
> 1; by using the optional sortop field in the aggregator.
> However, this optimization is disabl
Matthias van de Meent writes:
> PFA the small patch that implements this.
I don't have enough knowledge to have an opinion on most of the patch
other than it looks okay at a glance, but the list API usage could be
updated to more modern variants:
> diff --git a/src/backend/optimizer/plan/planag
Hi,
As you may know, aggregates like SELECT MIN(unique1) FROM tenk1; are
rewritten as SELECT unique1 FROM tenk1 ORDER BY unique1 USING < LIMIT
1; by using the optional sortop field in the aggregator.
However, this optimization is disabled for clauses that in itself have
an ORDER BY clause such as
15 matches
Mail list logo
