On 5 August 2015 at 03:03, Heikki Linnakangas wrote:
> On 08/03/2015 08:53 AM, David Rowley wrote:
>
>> Attached is a delta patched which is based
>> on sharing_aggstate-heikki-2.patch to fix up the out-dated comments and
>> also a few more test scenarios which test the sharing works with matchin
On 08/03/2015 08:53 AM, David Rowley wrote:
Attached is a delta patched which is based
on sharing_aggstate-heikki-2.patch to fix up the out-dated comments and
also a few more test scenarios which test the sharing works with matching
INITCOND and that it does not when they don't match.
What do yo
On 29 July 2015 at 03:45, Heikki Linnakangas wrote:
> On 07/28/2015 04:14 AM, David Rowley wrote:
>
>> On 27 July 2015 at 20:11, Heikki Linnakangas wrote:
>>
>> On 07/27/2015 08:34 AM, David Rowley wrote:
>>>
>>> In this function I also wasn't quite sure if it was with comparing both
non-NU
Heikki Linnakangas writes:
> On 07/28/2015 07:18 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> BTW, we're also not checking if the transition or final functions are
>>> volatile. But that was the same before this patch too.
>> Up to now it hasn't mattered.
> Yes, it has. We combine iden
On 07/28/2015 07:18 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 07/28/2015 04:14 AM, David Rowley wrote:
Yeah, a volatile input function seems highly unlikely, but who knows.
We have a project policy against volatile I/O functions. One reason why
is that it would break the assumption t
Heikki Linnakangas writes:
> On 07/28/2015 04:14 AM, David Rowley wrote:
>> I'd not thought of an input function being volatile before, but I guess
>> it's possible, which makes me a bit scared that we could be treading on
>> ground we shouldn't be. I know it's more of an output function thing tha
On 07/28/2015 04:14 AM, David Rowley wrote:
On 27 July 2015 at 20:11, Heikki Linnakangas wrote:
On 07/27/2015 08:34 AM, David Rowley wrote:
In this function I also wasn't quite sure if it was with comparing both
non-NULL INITCOND's here. I believe my code comments may slightly
contradict wha
On 27 July 2015 at 20:11, Heikki Linnakangas wrote:
> On 07/27/2015 08:34 AM, David Rowley wrote:
>
>> - * agg_input_types, agg_state_type, agg_result_type identify the input,
>> - * transition, and result types of the aggregate. These should all be
>> - * resolved to actual types (ie, none shou
On 27 July 2015 at 20:11, Heikki Linnakangas wrote:
> On 07/27/2015 08:34 AM, David Rowley wrote:
>
> In this function I also wasn't quite sure if it was with comparing both
>> non-NULL INITCOND's here. I believe my code comments may slightly
>> contradict what the code actually does, as the com
On 07/27/2015 08:34 AM, David Rowley wrote:
- * agg_input_types, agg_state_type, agg_result_type identify the input,
- * transition, and result types of the aggregate. These should all be
- * resolved to actual types (ie, none should ever be ANYELEMENT etc).
+ * agg_input_types identifies the in
On 27 July 2015 at 18:15, Haribabu Kommi wrote:
> On Thu, Jul 9, 2015 at 7:44 PM, David Rowley
> wrote:
> > On 15 June 2015 at 12:05, David Rowley
> wrote:
> >>
> >>
> >> This basically allows an aggregate's state to be shared between other
> >> aggregate functions when both aggregate's transit
On Thu, Jul 9, 2015 at 7:44 PM, David Rowley
wrote:
> On 15 June 2015 at 12:05, David Rowley wrote:
>>
>>
>> This basically allows an aggregate's state to be shared between other
>> aggregate functions when both aggregate's transition functions (and a few
>> other things) match
>> There's quite a
On 27 July 2015 at 03:24, Heikki Linnakangas wrote:
> On 07/09/2015 12:44 PM, David Rowley wrote:
>
>> On 15 June 2015 at 12:05, David Rowley
>> wrote:
>>
>>
>>> This basically allows an aggregate's state to be shared between other
>>> aggregate functions when both aggregate's transition functio
On 07/09/2015 12:44 PM, David Rowley wrote:
On 15 June 2015 at 12:05, David Rowley wrote:
This basically allows an aggregate's state to be shared between other
aggregate functions when both aggregate's transition functions (and a few
other things) match
There's quite a number of aggregates in
On 15 June 2015 at 12:05, David Rowley wrote:
>
> This basically allows an aggregate's state to be shared between other
> aggregate functions when both aggregate's transition functions (and a few
> other things) match
> There's quite a number of aggregates in our standard set which will
> benefit
Simon and I have been going over some ideas about how to make improvements
to aggregate performance by cutting down on the duplicate work that's done
when 2 aggregate functions are used where one knows how to satisfy all the
requirements of the other.
To cut a long story short, all our ideas will
16 matches
Mail list logo
