On Thu, 25 Jul 2019 at 11:33, Andres Freund wrote:
>
> On 2019-07-25 10:36:26 +1200, David Rowley wrote:
> > 2) Planner trying to give nodeAgg.c a sorted path to work with on
> > DISTINCT / ORDER BY aggs
>
> That'll have to be a best effort thing though, i.e. there'll always be
> cases where
Hi,
On 2019-07-25 10:36:26 +1200, David Rowley wrote:
> I'd like to do > much more in nodeAgg.c, TBH. It would be good to remove some
> code from
> nodeAgg.c and put it in the planner.
Indeed!
> I'd like to see:
>
> 1) Planner doing the Aggref merging for aggregates with the same
> transfn
On Thu, 25 Jul 2019 at 06:52, Andres Freund wrote:
> Now that master is open for development, and you have a commit bit, are
> you planning to go forward with this on your own?
I plan to, but it's not a high priority at the moment. I'd like to do
much more in nodeAgg.c, TBH. It would be good to
Hi,
On 2019-05-20 17:27:10 +1200, David Rowley wrote:
> On Mon, 20 May 2019 at 13:20, Andres Freund wrote:
> > How
> > about we have something roughly like:
> >
> > int numTransFnArgs = -1;
> > int numCombineFnArgs = -1;
> > Oid
Hi,
On May 20, 2019 6:23:46 AM PDT, Robert Haas wrote:
>On Sun, May 19, 2019 at 2:36 PM Andres Freund
>wrote:
>> Not sure I understand the distinction you're trying to make with the
>> variable renaming. The combine function is also a transition
>function,
>> no?
>
>Not in my mental model.
On Sun, May 19, 2019 at 2:36 PM Andres Freund wrote:
> Not sure I understand the distinction you're trying to make with the
> variable renaming. The combine function is also a transition function,
> no?
Not in my mental model. It's true that a combine function is used in
a similar manner to a
On Mon, 20 May 2019 at 19:59, Kyotaro HORIGUCHI
wrote:
> -numArguments = get_aggregate_argtypes(aggref, inputTypes);
> +numTransFnArgs = get_aggregate_argtypes(aggref, transFnInputTypes);
>
> If the function retrieves argument types of transform functions,
> it would be better
Hello.
I couldn't understand the multiple argument lists with confident
so the patch was born from a guess^^; Sorry for the confusing but
I'm relieved by knowing that it was not so easy to understand.
At Mon, 20 May 2019 17:27:10 +1200, David Rowley
wrote in
> On Mon, 20 May 2019 at 13:20,
On Mon, 20 May 2019 at 13:20, Andres Freund wrote:
> How
> about we have something roughly like:
>
> int numTransFnArgs = -1;
> int numCombineFnArgs = -1;
> Oid transFnInputTypes[FUNC_MAX_ARGS];
> Oid
Hi,
Thanks to all for reporting, helping to identify and finally patch the
problem!
On 2019-05-20 10:36:43 +1200, David Rowley wrote:
> On Mon, 20 May 2019 at 06:36, Andres Freund wrote:
> > > diff --git a/src/backend/executor/nodeAgg.c
> > > b/src/backend/executor/nodeAgg.c
> > > index
On Mon, 20 May 2019 at 06:36, Andres Freund wrote:
> > Isn't it more due to the lack of any aggregates with > 1 arg having a
> > combine function?
>
> I'm not sure I follow? regr_count() already was in 9.6? Including a
> combine function?
Oops, that line I meant to delete before sending.
> >
Hi,
On 2019-05-19 20:18:38 +1200, David Rowley wrote:
> On Fri, 17 May 2019 at 15:04, Andres Freund wrote:
> >
> > On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > > In a second look, I seems to me that the right thing to do here
> > > is setting numInputs instaed of numArguments to
On Fri, 17 May 2019 at 15:04, Andres Freund wrote:
>
> On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > In a second look, I seems to me that the right thing to do here
> > is setting numInputs instaed of numArguments to numTransInputs in
> > combining step.
>
> Yea, to me this just
On Sun, 19 May 2019 at 07:37, Andres Freund wrote:
> David, anyone, any comments?
Looking at this now.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
David, anyone, any comments?
On 2019-05-16 20:04:04 -0700, Andres Freund wrote:
> On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > This behavior is introduced by 69c3936a14 (in v11). At that time
> > FunctionCallInfoData is pallioc0'ed and has fixed length members
> > arg[6] and
Hi,
On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> This behavior is introduced by 69c3936a14 (in v11). At that time
> FunctionCallInfoData is pallioc0'ed and has fixed length members
> arg[6] and argnull[7]. So nulls[1] is always false even if nargs
> = 1 so the issue had not been
At Thu, 09 May 2019 11:17:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190509.111746.217492977.horiguchi.kyot...@lab.ntt.co.jp>
> Valgrind doesn't detect the overruning read since the block
> doesn't has 'MEMNOACCESS' region, since the requested size is
> just 64 bytes.
>
>
Hello. There is an unfortunate story on this issue.
At Wed, 8 May 2019 14:56:25 -0400, Andrew Dunstan
wrote in
<7969b496-096a-bf9b-2a03-4706baa4c...@2ndquadrant.com>
>
> On 5/8/19 12:41 PM, Greg Stark wrote:
> > Don't we have a build farm animal that runs under valgrind that would
> > have
On 5/8/19 12:41 PM, Greg Stark wrote:
> Don't we have a build farm animal that runs under valgrind that would
> have caught this?
>
>
There are two animals running under valgrind: lousyjack and skink.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL
Don't we have a build farm animal that runs under valgrind that would
have caught this?
t from "Statistical aggregate functions are not
> > working with partitionwise aggregate " to "Statistical aggregate functions
> > are not working with PARTIAL aggregation".
> >
> > original reported test case and discussion can be found at below link.
> &
On Wed, May 8, 2019 at 12:09 AM Kyotaro HORIGUCHI
wrote:
> By the way, as mentioned above, this issue exists since 11 but
> harms at 12. Is this an open item, or older bug?
Sounds more like an open item to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
from "Statistical aggregate functions are not
> > > working with partitionwise aggregate " to "Statistical aggregate functions
> > > are not working with PARTIAL aggregation".
> > >
> > > original reported test case and discussion can be found
is reproducible without partition-wise aggregate also,
> > changing email subject from "Statistical aggregate functions are not
> > working with partitionwise aggregate " to "Statistical aggregate functions
> > are not working with PARTIAL aggregation".
> &g
"Statistical aggregate functions
> are not working with PARTIAL aggregation".
>
> original reported test case and discussion can be found at below link.
> https://www.postgresql.org/message-id/flat/CAKcux6%3DuZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew%40mail.gmail.com
Hi,
As this issue is reproducible without partition-wise aggregate also,
changing email subject from "Statistical aggregate functions are not
working with partitionwise aggregate " to "Statistical aggregate functions
are not working with PARTIAL aggregation".
origina
26 matches
Mail list logo
