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

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.

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