Robert Haas <robertmh...@gmail.com> writes:
> On Tue, May 22, 2012 at 1:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Currently, the planner keeps paths that appear to win on the grounds of
>> either cheapest startup cost or cheapest total cost. It suddenly struck
>> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor
>> fast-start preference, etc) we could know a-priori that cheapest startup
>> cost is not going to be interesting, and hence immediately discard any
>> path that doesn't win on total cost.
>>
>> This would require some additional logic to detect whether the case
>> applies, as well as extra complexity in add_path. So it's possible
>> that it wouldn't be worthwhile overall. Still, it seems like it might
>> be a useful idea to investigate.
>>
>> Thoughts?
> Yeah, I think we should investigate that. Presumably you could easily
> have a situation where one part of the tree is under a LIMIT or EXISTS
> and therefore needs to preserve fast-start plans but the rest of the
> (potentially large) tree isn't, so we need something fairly
> fine-grained, I think. Maybe we could add a flag to each RelOptInfo
> indicating whether fast-start plans should be kept, or something like
> that.
I got around to looking at this finally. It turns out to be a big win,
at least for queries without any LIMIT or other reason to worry about
fast-start plans.
As things currently stand, there isn't any reason to control the
decision at finer than per-subquery level. I did it the way you suggest
above anyway, with a per-RelOptInfo flag, because add_path() is passed
only a RelOptInfo and not the PlannerInfo root structure. We could
have changed that of course, but it would have meant changing an API
used by FDWs, which would be annoying. It seems possible that in future
somebody might think of a way to determine this on a per-relation level,
so I thought this design might be a bit more future-proof anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
