Re: Performance Issues (was: "like" vs "substring" again)
От
John D. Burger
Тема
Re: Performance Issues (was: "like" vs "substring" again)
Дата
Msg-id
A9A0E5C9-0EDA-4155-BFE9-65F4D59600F5@mitre.org
Ответ на
Performance Issues (was: "like" vs "substring" again) (Christian Schröder)
Список
Дерево обсуждения
"like" vs "substring" again Christian Schröder <cs@deriva.de>
Performance Issues (was: "like" vs "substring" again) Christian Schröder <cs@deriva.de>
Re: Performance Issues (was: "like" vs "substring" again) "John D. Burger" <john@mitre.org>
Re: Performance Issues Christian Schröder <cs@deriva.de>
Re: Performance Issues Alvaro Herrera <alvherre@commandprompt.com>
Re: Performance Issues Christian Schröder <cs@deriva.de>
Re: Performance Issues Alvaro Herrera <alvherre@commandprompt.com>
Re: Performance Issues "Peter Childs" <peterachilds@gmail.com>
Christian Schröder wrote:
> Or would it be possible to tweak how the planner determines the
> selectivity? I have read in the docs (chapter 54.1) that in case of
> more than one condition in the where clause, independency is
> assumed. In my case ("... where test like '11%' and test not like
> '113%'") this is clearly not the case, so it might be an
> interesting point to address.
I think the planner does think about the interactions of
inequalities, so if you can express your query with less-than and
friends, or even with BETWEEN, you might get a better plan. I don't
know the details of your setup, but you can do things like this with
any ordered type:
where test between '11' and '113'
or test >= '114'
I know this does not match the exact semantics of your query, but
hopefully you get the idea.
- John D. Burger
MITRE
В списке pgsql-general по дате отправления