On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
