index scan on =, but not < ? - Mailing list pgsql-performance

From Rick Schumeyer
Subject index scan on =, but not < ?
Date
Msg-id 001f01c5240d$a920c8c0$0200a8c0@dell8200
Whole thread Raw
Responses Re: index scan on =, but not < ?  (Thomas F.O'Connell <tfo@sitening.com>)
Re: index scan on =, but not < ?  (John Arbash Meinel <john@arbash-meinel.com>)
Re: index scan on =, but not < ?  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: index scan on =, but not < ?  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-performance

I have two index questions.  The first is about an issue that has been recently discussed,

and I just wanted to be sure of my understanding.  Functions like count(), max(), etc. will

use sequential scans instead of index scans because the index doesn’t know which rows

are actually visible…is this correct?

 

Second:

 

I created an index in a table with over 10 million rows.

The index is on field x, which is a double.

 

The following command, as I expected, results in an index scan:

 

=# explain select * from data where x = 0;

                               QUERY PLAN

-------------------------------------------------------------------------

 Index Scan using data_x_ix on data  (cost=0.00..78.25 rows=19 width=34)

   Index Cond: (x = 0::double precision)

(2 rows)

 

 

But this command, in which the only difference if > instead of =, is a sequential scan.

 

=# explain select * from data where x > 0;

                            QUERY PLAN

------------------------------------------------------------------

 Seq Scan on data  (cost=0.00..1722605.20 rows=62350411 width=34)

   Filter: (x > 0::double precision)

(2 rows)

 

Why is this?

(This is with pg 8.0.1 on a PC running FC3 with 1GB ram…if it matters)

pgsql-performance by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: bad plan
Next
From: Thomas F.O'Connell
Date:
Subject: Re: index scan on =, but not < ?