Re: [PATCH] Lazy hashaggregate when no aggregation is needed

On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> I'm confused by this remark, because surely the query planner does it this
>>> way only if there's no LIMIT.  When there is a LIMIT, we choose based on
>>> the startup cost plus the estimated fraction of the total cost we expect
>>> to pay based on dividing the LIMIT by the overall row count estimate.  Or
>>> is this not what you're talking about?
>>
>> I think that Ants is pointing the way of estimating costs in
>> choose_hashed_grouping()/choose_hashed_distinct(), ie cost_agg() for
>> cheapest_path + hashagg, where the costs are calculated based on the total
>> cost only of cheapest_path.  I think that it might be good to do cost_agg()
>> for the discussed case with the AGG_SORTED strategy, not the AGG_HASHED
>> strategy.
>
> Well, Ants already made some adjustments to those functions; not sure
> if this means they need some more adjustment, but I don't see that
> there's a general problem with the costing algorithm around LIMIT.

Ants, do you intend to update this patch for this CommitFest? Or at
all? It seems nobody's too excited about this, so I'm not sure
whether it makes sense for you to put more work on it. But please
advise as to your plans.

Thanks,

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company