Re: seqscan instead of index scan - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: seqscan instead of index scan
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A748E@Herge.rcsinc.local
Whole thread Raw
In response to seqscan instead of index scan  (Martin Sarsale <martin@emepe3.net>)
Responses Re: seqscan instead of index scan
Re: seqscan instead of index scan
List 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 by date:

Previous
From: Martin Sarsale
Date:
Subject: Re: seqscan instead of index scan
Next
From: Bruno Wolff III
Date:
Subject: Re: seqscan instead of index scan