Re: seqscan instead of index scan

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: seqscan instead of index scan
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A748E@Herge.rcsinc.local
обсуждение исходный текст
Ответ на seqscan instead of index scan  (Martin Sarsale <martin@emepe3.net>)
Ответы Re: seqscan instead of index scan
Re: seqscan instead of index scan
Список pgsql-performance
> On Mon, 2004-08-30 at 15:06, Merlin Moncure wrote:
> > create function is_somethingable (ctype, dtype) returns boolean as
>
> Thanks, but I would prefer a simpler solution.
>
> I would like to know why this uses a seqscan instead of an index scan:
>
> create index t_idx on t((c+d));
> select * from t where c+d > 0;
>

hmmm, please define simple.

Using a functional index you can define an index around the way you
access the data.  There is no faster or better way to do it...this is a
mathematical truth, not a problem with the planner.  Why not use the
right tool for the job?  A boolean index is super-efficient both in disk
space and cache utilization.

Multiple column indexes are useless for 'or' combinations! (however they
are a huge win for 'and' combinations because you don't have to merge).

With an 'or' expression, the planner must use one index or the other, or
use both and merge the results.  When and what the planner uses is an
educated guess based on statistics.

Also, your function can be changed...why fill all your queries with
Boolean cruft when you can abstract it into the database and reap the
speed savings at the same time?  I think it's time to rethink the
concept of 'simple'.

Constructive criticism all,
Merlin



В списке pgsql-performance по дате отправления:

Предыдущее
От: Martin Sarsale
Дата:
Сообщение: Re: seqscan instead of index scan
Следующее
От: Bruno Wolff III
Дата:
Сообщение: Re: seqscan instead of index scan