> AFAICS the problem is not restricted to LIKE, we can easily find a lot
of
> similar problems caused by the actual parameters. For example, SeqScan
vs.
> IndexScan vs. BitmapIndexScan for a range query. So an improvement is
> definitely needed.
> Another way is to generate a plan on the fly. What we do is to let
some
> REPLAN nodes sit on top of some critical plan node: at the execution,
we
> will compare the actual numbers we get and the estimated number we
have
Since we are deciding this on histogram data, it seems we could "store"
the ranges (and exception values) where this plan is not good, and
replan in
case the new value does not fit.
This would also imply, that we postpone (part of the) planning until we
get the
first values, when the node cost largly depends on the supplied value.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
