On 08/28/2014 03:46 AM, Claudio Freire wrote:
> You can't with mean and stddev, only with associative aggregates.
>
> That's min, max, sum, bit_and, bit_or, bool_and, bool_or, count.
You could with a new helper function to merge the temporary states for
each scan though.
In the case of mean, for
On Wed, Aug 27, 2014 at 6:46 PM, Merlin Moncure wrote:
>
> Yeah: I was overthinking it. My mind was on parallel processing of
> the aggregate (which is not what Pavel was proposing) because that
> just happens to be what I'm working on currently -- using dblink to
> decompose various aggregates
On Wed, Aug 27, 2014 at 3:27 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> associative bit just makes it easier (which is important of course!).
>> mean for example can be pushed down if the 'pushed down' aggregates
>> return to the count to the "reaggregator" so that you can weight the
>> fina
On 27 Srpen 2014, 21:41, Merlin Moncure wrote:
> On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule
>>
>> Are there some plans to use partitioning for aggregation?
>
> Besides min/max, what other aggregates (mean/stddev come to mind)
> would you optimize and how would you determine which ones could be
2014-08-27 22:27 GMT+02:00 Tom Lane :
> Merlin Moncure writes:
> > associative bit just makes it easier (which is important of course!).
> > mean for example can be pushed down if the 'pushed down' aggregates
> > return to the count to the "reaggregator" so that you can weight the
> > final avera
Merlin Moncure writes:
> associative bit just makes it easier (which is important of course!).
> mean for example can be pushed down if the 'pushed down' aggregates
> return to the count to the "reaggregator" so that you can weight the
> final average. that's a lot more complicated though.
The r
On Wed, Aug 27, 2014 at 2:46 PM, Claudio Freire wrote:
> On Wed, Aug 27, 2014 at 4:41 PM, Merlin Moncure wrote:
>> On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule
>> wrote:
>>> Hi
>>>
>>> one user asked about using a partitioning for faster aggregates queries.
>>>
>>> I found so there is not any
2014-08-27 21:46 GMT+02:00 Claudio Freire :
> On Wed, Aug 27, 2014 at 4:41 PM, Merlin Moncure
> wrote:
> > On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule
> wrote:
> >> Hi
> >>
> >> one user asked about using a partitioning for faster aggregates queries.
> >>
> >> I found so there is not any opti
2014-08-27 21:41 GMT+02:00 Merlin Moncure :
> On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule
> wrote:
> > Hi
> >
> > one user asked about using a partitioning for faster aggregates queries.
> >
> > I found so there is not any optimization.
> >
> > create table x1(a int, d date);
> > create table
On Wed, Aug 27, 2014 at 4:41 PM, Merlin Moncure wrote:
> On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule
> wrote:
>> Hi
>>
>> one user asked about using a partitioning for faster aggregates queries.
>>
>> I found so there is not any optimization.
>>
>> create table x1(a int, d date);
>> create ta
On Wed, Aug 27, 2014 at 2:07 PM, Pavel Stehule wrote:
> Hi
>
> one user asked about using a partitioning for faster aggregates queries.
>
> I found so there is not any optimization.
>
> create table x1(a int, d date);
> create table x_1 ( check(d = '2014-01-01'::date)) inherits(x1);
> create table
Hi
one user asked about using a partitioning for faster aggregates queries.
I found so there is not any optimization.
create table x1(a int, d date);
create table x_1 ( check(d = '2014-01-01'::date)) inherits(x1);
create table x_2 ( check(d = '2014-01-02'::date)) inherits(x1);
create table x_3 (
12 matches
Mail list logo
