Обсуждение: set the cost of an aggregate function

Hi,

why we can't do $subject? it could have any benefit on the planner?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

2009/11/30 Jaime Casanova <jcasanov@systemguards.com.ec>:
> Hi,
>
> why we can't do $subject? it could have any benefit on the planner?
>

seems like while we can set the cost of the state transition function,
that cost is not propagated...


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

On Mon, Nov 30, 2009 at 11:53 AM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
> 2009/11/30 Jaime Casanova <jcasanov@systemguards.com.ec>:
>> Hi,
>>
>> why we can't do $subject? it could have any benefit on the planner?
>>
>
> seems like while we can set the cost of the state transition function,
> that cost is not propagated...

I thought for sure you must be wrong about this, but I just read the
source code and, sure enough, the cost of the transition and final
functions are totally ignored.  In fact, there's a comment about this
in cost_agg():
        * Note: ideally we should use the pg_proc.procost costs of each        * aggregate's component functions, but
fornow that seems like an        * excessive amount of work.
 

...Robert

On Mon, 2009-11-30 at 11:53 -0500, Jaime Casanova wrote:
> 2009/11/30 Jaime Casanova <jcasanov@systemguards.com.ec>:
> > Hi,
> >
> > why we can't do $subject? it could have any benefit on the planner?
> >
> 
> seems like while we can set the cost of the state transition function,
> that cost is not propagated...

The cost of comparison functions is not considered in cost_sort()
either.

The answer is nobody got round to enhancing this yet and well considered
proposals and subsequent patches would be welcome. 

-- Simon Riggs           www.2ndQuadrant.com

On Thu, Dec 3, 2009 at 7:19 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> The answer is nobody got round to enhancing this yet and well considered
> proposals and subsequent patches would be welcome.
>

what is a well considered proposal in this area? the transition
function cost should be applied to every row cost (maybe multiplied to
cpu_operator_cost or cpu_tuple_cost) and the final function cost
should be applied just once, no?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157