On Fri, May 25, 2007 at 09:13:25AM +0100, Richard Huxton wrote:
> mark(at)mark(dot)mielke(dot)cc wrote:
> >>And since it's basically impossible to know the selectivity of this kind
> >>of where condition, I doubt the planner would ever realistically want to
> >>choose that plan anyway because of its poor worst-case behavior.
> >What is a real life example where an intelligent and researched
> >database application would issue a like or ilike query as their
> >primary condition in a situation where they expected very high
> >Avoiding a poor worst-case behaviour for a worst-case behaviour that
> >won't happen doesn't seem practical.
> But if you are also filtering on e.g. date, and that has an index with
> good selectivity, you're never going to use the text index anyway are
> you? If you've only got a dozen rows to check against, might as well
> just read them in.
> The only time it's worth considering the behaviour at all is *if* the
> worst-case is possible.
I notice you did not provide a real life example as requested. :-)
This seems like an ivory tower restriction. Not allowing best performance
in a common situation vs not allowing worst performance in a not-so-common
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2007-05-25 14:18:45|
|Subject: Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) |
|Previous:||From: Bastian Voigt||Date: 2007-05-25 14:11:45|
|Subject: Re: My quick and dirty "solution" (Re: Performance Problem
with Vacuum of bytea table (PG 8.0.13))|