Re: [HACKERS] WIP: Aggregation push-down

Richard Guo wrote: > Hi, > > I've been looking at the 'make_join_rel()' part of the patch, and I'm > aware that, if we are joining A and B, a 'grouped join rel (AB)' would > be created besides the 'plain join rel (AB)', and paths are added by 1) > applying partial aggregate to the paths of the

Re: [HACKERS] WIP: Aggregation push-down

Hi, I've been looking at the 'make_join_rel()' part of the patch, and I'm aware that, if we are joining A and B, a 'grouped join rel (AB)' would be created besides the 'plain join rel (AB)', and paths are added by 1) applying partial aggregate to the paths of the 'plain join rel (AB)', or 2)

Re: [HACKERS] WIP: Aggregation push-down

Tomas Vondra wrote: > Hi, > > I've been looking at the last version (v14) of this patch series, > submitted way back in July and unfortunately quiet since then. Antonin > is probably right one of the reasons for the lack of reviews is that it > requires interest/experience with planner. > >

Re: [HACKERS] WIP: Aggregation push-down

Hi, I've been looking at the last version (v14) of this patch series, submitted way back in July and unfortunately quiet since then. Antonin is probably right one of the reasons for the lack of reviews is that it requires interest/experience with planner. Initially it was also a bit hard to

Re: [HACKERS] WIP: Aggregation push-down

Alvaro Herrera wrote: > This stuff seems very useful. How come it sits unreviewed for so long? I think the review is hard for people who are not interested in the planner very much. And as for further development, there are a few design decisions that can hardly be resolved without Tom Lane's

Re: [HACKERS] WIP: Aggregation push-down

This stuff seems very useful. How come it sits unreviewed for so long? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] WIP: Aggregation push-down

Richard Guo wrote: > Another core dump for query below: > > select sum(t1.s1) from t1, t2, t3, t4 where t1.j1 = t2.j2 group by t1.g1, > t2.g2; > > This is due to a small mistake: > > diff --git a/src/backend/optimizer/util/relnode.c > b/src/backend/optimizer/util/relnode.c > index

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Jul 12, 2019 at 4:42 PM Antonin Houska wrote: > Richard Guo wrote: > > > I didn't fully follow the whole thread and mainly looked into the > > latest > > patch set. So what are the considerations for abandoning the > > aggmultifn > > concept? > > Originally the function was there to

Re: [HACKERS] WIP: Aggregation push-down

On Tue, Jul 9, 2019 at 9:47 PM Antonin Houska wrote: > Richard Guo wrote: > > > Another rebase is needed for the patches. > > Done. > I didn't fully follow the whole thread and mainly looked into the latest patch set. So what are the considerations for abandoning the aggmultifn concept? In my

Re: [HACKERS] WIP: Aggregation push-down

Richard Guo wrote: > Another rebase is needed for the patches. Done. -- Antonin Houska Web: https://www.cybertec-postgresql.com >From f656bd8d46afb9cb0a331cf3d34b9eed39f5e360 Mon Sep 17 00:00:00 2001 From: Antonin Houska Date: Tue, 9 Jul 2019 15:30:13 +0200 Subject: [PATCH 1/3] Introduce

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Mar 1, 2019 at 12:01 AM Antonin Houska wrote: > Tom Lane wrote: > > > Antonin Houska writes: > > > Michael Paquier wrote: > > >> Latest patch set fails to apply, so moved to next CF, waiting on > > >> author. > > > > > Rebased. > > > > This is in need of rebasing again :-(. I went

Re: [HACKERS] WIP: Aggregation push-down

Tom Lane wrote: > Antonin Houska writes: > > Michael Paquier wrote: > >> Latest patch set fails to apply, so moved to next CF, waiting on > >> author. > > > Rebased. > > This is in need of rebasing again :-(. I went ahead and pushed the 001 > part, since that seemed fairly uncontroversial.

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska writes: > Michael Paquier wrote: >> Latest patch set fails to apply, so moved to next CF, waiting on >> author. > Rebased. This is in need of rebasing again :-(. I went ahead and pushed the 001 part, since that seemed fairly uncontroversial. (Note that I changed

Re: [HACKERS] WIP: Aggregation push-down

On Tue, Jan 15, 2019 at 03:06:18PM +0100, Antonin Houska wrote: > This is the next version. A few more comments below. Latest patch set fails to apply, so moved to next CF, waiting on author. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] WIP: Aggregation push-down

Tom Lane wrote: > Antonin Houska writes: > > [ agg_pushdown_v8.tgz ] > > I spent a few hours looking at this today. Thanks! > It seems to me that at no point has there been a clear explanation of what > the patch is trying to accomplish, so let me see whether I've got it > straight or not.

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska writes: > [ agg_pushdown_v8.tgz ] I spent a few hours looking at this today. It seems to me that at no point has there been a clear explanation of what the patch is trying to accomplish, so let me see whether I've got it straight or not. (I suggest that something like this ought

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska wrote: > I've reworked the patch so that separate RelOptInfo is used for grouped > relation. The attached patch is only the core part. Neither postgres_fdw > changes nor the part that tries to avoid the final aggregation is included > here. I'll add these when the patch does not

Re: [HACKERS] WIP: Aggregation push-down

Robert Haas wrote: > On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska wrote: > > I spent some more time thinking about this. What about adding a new strategy > > number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber? > > For > > most types both HTEqualStrategyNumber and

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska wrote: > I spent some more time thinking about this. What about adding a new strategy > number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber? For > most types both HTEqualStrategyNumber and

Re: [HACKERS] WIP: Aggregation push-down

Robert Haas wrote: > On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote: > > I think of a variant of this: implement an universal function that tests the > > binary values for equality (besides the actual arguments, caller would have > > to > > pass

Re: [HACKERS] WIP: Aggregation push-down

On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote: > I think of a variant of this: implement an universal function that tests the > binary values for equality (besides the actual arguments, caller would have to > pass info like typlen, typalign, typbyval for each argument,

Re: [HACKERS] WIP: Aggregation push-down

On 01/29/18 03:32, Antonin Houska wrote: > Robert Haas wrote: >>> only take place if we had a special equality operator which distinguishes >>> the >>> *binary* values (I don't know yet how to store this operator the catalog --- ... >> We don't have an operator that tests

Re: [HACKERS] WIP: Aggregation push-down

Robert Haas wrote: > On Fri, Jan 26, 2018 at 8:04 AM, Antonin Houska wrote: > > So one problem is that the grouping expression can be inappropriate for > > partial aggregation even if there's no type change during the > > translation. What I consider

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Jan 26, 2018 at 8:04 AM, Antonin Houska wrote: > So one problem is that the grouping expression can be inappropriate for > partial aggregation even if there's no type change during the > translation. What I consider typical for this case is that the equality > operator

Re: [HACKERS] WIP: Aggregation push-down

Robert Haas wrote: > On Fri, Dec 22, 2017 at 10:43 AM, Antonin Houska wrote: > > Michael Paquier wrote: > >> On Sat, Nov 4, 2017 at 12:33 AM, Antonin Houska wrote: > >> > I'm not about to add any other

Re: [HACKERS] WIP: Aggregation push-down

On Fri, Dec 22, 2017 at 10:43 AM, Antonin Houska wrote: > Michael Paquier wrote: >> On Sat, Nov 4, 2017 at 12:33 AM, Antonin Houska wrote: >> > I'm not about to add any other features now. Implementation of the missing >> > parts