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 we'll
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 et
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 transFnI
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. It's
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 tr
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 that
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, And
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 combineFnInputTyp
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 d01fc4f
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.
> > Yea
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 num
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 seems
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 ar
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 revea
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.
>
> Thu
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 cau
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 De
Don't we have a build farm animal that runs under valgrind that would
have caught this?
On Wed, May 08, 2019 at 01:09:23PM +0900, Kyotaro HORIGUCHI wrote:
At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp>
At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wro
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 Co
At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.j
At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
> wrote in
>
> > Hi,
> > As this issue is reproducible without partition-wise
Hello.
At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
wrote in
> 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 functio
25 matches
Mail list logo
