On 10 June 2015 at 02:26, Tom Lane wrote:
> Kevin Grittner writes:
> > David Rowley wrote:
> >> [ avoid duplicate calculations for related aggregates ]
>
> > From the information you have proposed storing, with cost factors
> > associated with the functions, it seems technically possible to
> >
On 10 June 2015 at 01:53, Kevin Grittner wrote:
> David Rowley wrote:
>
> > 3. Add logic in the planner to look for look for supporting
> > cases. With logic something along the lines of:
> >
> > a. Does the query have any aggregates? If not -> return;
> > b. Does the query have more than 1
Tom Lane wrote:
> Kevin Grittner writes:
>> David Rowley wrote:
>>> [ avoid duplicate calculations for related aggregates ]
>> From the information you have proposed storing, with cost factors
>> associated with the functions, it seems technically possible to
>> infer that you could run (for ex
Kevin Grittner writes:
> David Rowley wrote:
>> [ avoid duplicate calculations for related aggregates ]
> From the information you have proposed storing, with cost factors
> associated with the functions, it seems technically possible to
> infer that you could run (for example) the avg() aggrega
David Rowley wrote:
> The idea is that we skip a major chunk of processing in
> situations like:
>
> SELECT avg(x),sum(x),count(x) FROM bigtable;
>
> Because avg(x) already technically knows what the values of
> sum(x) and count(x) are.
That has occurred to me as a possible optimization, but I h
I believe this is an idea that's been discussed before, but I'm not exactly
sure where that happened:
Overview:
The idea is that we skip a major chunk of processing in situations like:
SELECT avg(x),sum(x),count(x) FROM bigtable;
Because avg(x) already technically knows what the values of sum(x
