Andrei Lepikhov writes:
> Rebase on current master.
I started to look at v5, and was immediately put off by the fact
that its documentation of the new support request type consists of
precisely zero words. You have the wrong idea of what is required
when adding a support request. The specificat
Rebase on current master.
--
regards, Andrei LepikhovFrom 79dee863be9c3f400c04d74f4e8493c8929eefbe Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Tue, 4 Mar 2025 15:24:28 +0100
Subject: [PATCH v5] Add prosupport helpers to aggregate functions.
Following the spirit of ed1a88d, add a p
On 12/11/24 07:22, Michael Paquier wrote:
On Fri, Nov 08, 2024 at 01:05:04PM +0700, Andrei Lepikhov wrote:
Rebase onto current master and slight improvement.
Your patch is failing in the CI, please rebase. I have it to the next
CF for now, waiting on author.
Thanks,
I overlooked the fact tha
On 11/12/2024 07:22, Michael Paquier wrote:
On Fri, Nov 08, 2024 at 01:05:04PM +0700, Andrei Lepikhov wrote:
Rebase onto current master and slight improvement.
Your patch is failing in the CI, please rebase. I have it to the next
CF for now, waiting on author.
Thanks! I have observed such iss
On Fri, Nov 08, 2024 at 01:05:04PM +0700, Andrei Lepikhov wrote:
> Rebase onto current master and slight improvement.
Your patch is failing in the CI, please rebase. I have it to the next
CF for now, waiting on author.
--
Michael
signature.asc
Description: PGP signature
On 10/8/24 16:22, Andrei Lepikhov wrote:
On 10/8/24 13:06, David Rowley wrote:
On Tue, 8 Oct 2024 at 18:47, Andrei Lepikhov wrote:
Thanks, I suppose CATALOG_VERSION_NO was the only reason for this fail.
Please leave the cat version bump out of your patch. It's a waste of
time and resource if
On 10/8/24 13:06, David Rowley wrote:
On Tue, 8 Oct 2024 at 18:47, Andrei Lepikhov wrote:
Thanks, I suppose CATALOG_VERSION_NO was the only reason for this fail.
Please leave the cat version bump out of your patch. It's a waste of
time and resource if you plan to post another patch every time
On Tue, 8 Oct 2024 at 18:47, Andrei Lepikhov wrote:
> Thanks, I suppose CATALOG_VERSION_NO was the only reason for this fail.
Please leave the cat version bump out of your patch. It's a waste of
time and resource if you plan to post another patch every time a
committer bumps the cat version.
Dav
On 10/8/24 08:19, Michael Paquier wrote:
On Tue, Oct 01, 2024 at 04:25:59PM +0700, Andrei Lepikhov wrote:
I have written a sketch patch to implement the idea with aggregate
prosupport in code - see the attachment.
My intention was to provide an example, not a ready-to-commit patch.
As I see, the
On Tue, Oct 01, 2024 at 04:25:59PM +0700, Andrei Lepikhov wrote:
> I have written a sketch patch to implement the idea with aggregate
> prosupport in code - see the attachment.
> My intention was to provide an example, not a ready-to-commit patch.
> As I see, the only problem there lies in the test
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
25 matches
Mail list logo
