I've been looking more closely at add_path() and related functions
while trying to decide exactly how I want to handle cases where all
the available paths for a relation are parameterized (because it's got
unresolved lateral references). It suddenly struck me that I missed
a bet while revising that logic for 9.2. I hacked add_path() so that
it would ignore pathkeys for parameterized paths, essentially creating
a policy that a parameterized path can't win on sort order. (Which is
reasonable since it's going to end up on the inside of a nestloop, where
sort ordering won't help anything.) However, it's still giving credit
to parameterized paths if they have a cheap startup cost --- and that's
equally uninteresting for anything on the inside of a nestloop.
What we should do is tweak add_path() so that it also discounts startup
cost as a figure of merit for parameterized paths. (This seems to be
reasonably easy to do by making compare_path_costs_fuzzily not allow
a parameterized path to win on the basis of startup cost. We should
also teach add_path_precheck about that.) This gives us two benefits:
1. Slightly fewer parameterized paths survive the add_path tournament.
Since the others were losers anyway, this saves cycles with no downside.
2. AFAICS, the re-comparisons being done in add_parameterized_path()
become entirely unnecessary. Any parameterized path that has survived
until we reach set_cheapest must win on total cost or rowcount compared
to others of its parameterization. All such paths seem worthy to be
considered in the parts of joinpath.c that accept parameterized input
paths. So we can replace that whole step by just building a list of
surviving parameterized paths and sticking it into
rel->cheapest_parameterized_paths. (I also thought for a bit about
dispensing with that list completely, and just scanning rel->pathlist
looking for parameterized paths. But experimentation suggests there
are often dozens of surviving non-parameterized paths and few if any
parameterized ones, so scanning the whole pathlist to find the latter
seems like a loser.)
I shall manfully resist the temptation to retrofit this idea into 9.2,
but I'm going to go do it in HEAD ...
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
