2024-01 Commitfest.
Hi, this patch was marked in CF as "Needs Review", but there has been
no activity on this thread for 9+ months.
Since there seems not much interest, I have changed the status to
"Returned with Feedback" [1]. Feel free to propose a stronger use case
for the patch and add an ent
It looks like in November 2022 Tomas Vondra said:
> I did a quick initial review of the v20 patch series.
> I plan to do a
more thorough review over the next couple days, if time permits.
> In
general I think the patch is in pretty good shape.
Following which Antonin Houska updated the patch resp
On Thu, 5 Jan 2023 at 02:59, Antonin Houska wrote:
>
> vignesh C wrote:
>
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> > patch:
And again...
Setting this to Waiting on Author for the moment.
Do you think this patch is likely to be ready for this release or th
On Thu, 17 Nov 2022 at 16:34, Antonin Houska wrote:
>
> Tomas Vondra wrote:
>
> > Hi,
> >
> > I did a quick initial review of the v20 patch series. I plan to do a
> > more thorough review over the next couple days, if time permits. In
> > general I think the patch is in pretty good shape.
>
> Tha
Hi everyone.
I develop postgresql's extension such as fdw in my work.
I'm interested in using postgresql for OLAP.
After [1] having been withdrawn, I reviewed [1].
I think that this patch is realy useful when using OLAP queries.
Furthermore, I think it would be more useful if this patch works on
Hi everyone.
I develop postgresql's extension such as fdw in my work.
I'm interested in using postgresql for OLAP.
I think that this patch is realy useful when using OLAP queries.
Furthermore, I think it would be more useful if this patch works on a foreign
table.
Actually, I changed this patc
On 3/11/21 5:10 AM, Antonin Houska wrote:
David Steele wrote:
On 7/3/20 6:07 AM, Laurenz Albe wrote:
On Thu, 2020-07-02 at 14:39 +0200, Daniel Gustafsson wrote:
This version now fails to apply to HEAD, with what looks like like a trivial
error in the expected test output. Can you please sub
David Steele wrote:
> On 7/3/20 6:07 AM, Laurenz Albe wrote:
> > On Thu, 2020-07-02 at 14:39 +0200, Daniel Gustafsson wrote:
> >> This version now fails to apply to HEAD, with what looks like like a
> >> trivial
> >> error in the expected test output. Can you please submit a rebased
> >> versi
On 7/3/20 6:07 AM, Laurenz Albe wrote:
On Thu, 2020-07-02 at 14:39 +0200, Daniel Gustafsson wrote:
This version now fails to apply to HEAD, with what looks like like a trivial
error in the expected test output. Can you please submit a rebased version so
we can see it run in the patch tester CI?
> On 19 May 2020, at 10:17, Antonin Houska wrote:
> The next version is attached.
This version now fails to apply to HEAD, with what looks like like a trivial
error in the expected test output. Can you please submit a rebased version so
we can see it run in the patch tester CI? I'm marking the
On Fri, Apr 24, 2020 at 8:10 PM Antonin Houska wrote:
> Andy Fan wrote:
>
> > The more tests on your patch, the more powerful I feel it is!
>
> Thanks for the appreciation. Given the poor progress it's increasingly hard
> for me to find motivation to work on it. I'll try to be more professional
Andy Fan wrote:
> > 1) v14-0001-Introduce-RelInfoList-structure.patch
> > -
> >
> > - I'm not entirely sure why we need this change. We had the list+hash
> > before, so I assume we do this because we need the output functions?
>
> I believe
Andy Fan wrote:
> The more tests on your patch, the more powerful I feel it is!
Thanks for the appreciation. Given the poor progress it's increasingly hard
for me to find motivation to work on it. I'll try to be more professional :-)
> At the same time, I think the most difficult part to unders
>
> > 1) v14-0001-Introduce-RelInfoList-structure.patch
> > -
> >
> > - I'm not entirely sure why we need this change. We had the list+hash
> > before, so I assume we do this because we need the output functions?
>
> I believe that this is what Tom pr
On Thu, Feb 27, 2020 at 4:50 PM Antonin Houska wrote:
> legrand legrand wrote:
>
> > Antonin Houska-2 wrote
>
> > > Right now I recall two problems: 1) is the way I currently store
> > > RelOptInfo for the grouped relations correct?, 2) how should we handle
> > > types for which logical equality
legrand legrand wrote:
> Antonin Houska-2 wrote
> > Right now I recall two problems: 1) is the way I currently store
> > RelOptInfo for the grouped relations correct?, 2) how should we handle
> > types for which logical equality does not imply physical (byte-wise)
> > equality?
> >
> > Fortunat
Antonin Houska-2 wrote
> Alvaro Herrera <
> alvherre@
> > 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
> d
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 '
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) joini
legrand legrand wrote:
> set enable_agg_pushdown to true;
> isn't displayed in EXPLAIN (SETTINGS) syntax.
>
>
> The following modification seems to fix that:
>
> src/backend/utils/misc/guc.c
>
> {"enable_agg_pushdown", PGC_USERSET, QUERY_TUNING_METHOD,
>
Hello,
Thank you for this great feature !
I hope this will be reviewed/validated soon ;o)
Just a comment:
set enable_agg_pushdown to true;
isn't displayed in EXPLAIN (SETTINGS) syntax.
The following modification seems to fix that:
src/backend/utils/misc/guc.c
{"enable_agg_pu
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.
>
> Ini
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 unde
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 c
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
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 10becc0..9
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 supp
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
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 Rel
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 ahe
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.
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
estimate_hashag
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
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. (
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
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 se
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 HTBin
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 HTBinaryEqualStrategyNumber strategy
>
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 info like typlen, typalign, typbyval for e
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, and cache these
> fo
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 for binary equality, bu
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 typical for this case is that the equality
>
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 used to identify gro
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 features now. Implementation of the
> >> > missing
> >> > parts (see the TODO comments in t
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 (see the TODO comments in the code) is the next step. But what I'd
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 (see the TODO comments in the code) is the next step. But what I'd
> appreciate most is a feedback on the design. Thanks.
I am getting a conflict after apply
46 matches
Mail list logo
