On Fri, Jun 15, 2012 at 9:22 AM, Ants Aasma <ants@cybertec.at> wrote:
> Exactly. I think the first question for this patch should be whether
> this use-case is worth the complexity of the patch. I can't imagine
> any really compelling use cases that need an arbitrary distinct subset
> of results.
Me neither.
> The original complaint on -performance [1], didn't specify
> a real world use case, but it seemed to be a case of an ORM generating
> suboptimal queries. On the other hand, the patch itself is in my
> opinion rather simple, so it might be worth it.
Yeah.
> It has one outstanding issue, query_planner chooses the cheapest path
> based on total cost. This can be suboptimal when that path happens to
> have high startup cost. It seems to me that enabling the query_planner
> to find the cheapest unsorted path returning a limited amount of
> tuples would require some major surgery to the planner. To be clear,
> this is only a case of missed optimization, not a regression.
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?
> It won't help set returning functions because the tuplestore for those
> is fully materialized when the first row is fetched.
That's surely a problem for another day.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company