Re: index scan on =, but not < ?

From: Rick Schumeyer
Subject: Re: index scan on =, but not < ?
Date: ,
Msg-id: 002801c52411$6d510f40$0200a8c0@dell8200
(view: Whole thread, Raw)
In response to: Re: index scan on =, but not < ?  (Thomas F.O'Connell)
List: pgsql-performance

Tree view

index scan on =, but not < ?  ("Rick Schumeyer", )
 Re: index scan on =, but not < ?  (Thomas F.O'Connell, )
  Re: index scan on =, but not < ?  ("Rick Schumeyer", )
 Re: index scan on =, but not < ?  (John Arbash Meinel, )
 Re: index scan on =, but not < ?  (Dennis Bjorklund, )
 Re: index scan on =, but not < ?  (Bruno Wolff III, )
  Re: index scan on =, but not < ?  ("Jim C. Nasby", )
   Re: index scan on =, but not < ?  (Bruno Wolff III, )
    Re: index scan on =, but not < ?  ("Jim C. Nasby", )
     Re: index scan on =, but not < ?  (David Brown, )
      Re: index scan on =, but not < ?  (Manfred Koizar, )
    Re: index scan on =, but not < ?  (David Brown, )

That makes a lot of sense.  Sure enough, if I change the query from
WHERE x > 0  (which return a lot of rows) to
WHERE x > 0 AND x < 1
I now get an index scan.

> As for why you see index usage in your first example query and not your
> second: compare the number of rows in question. An index is extremely
> useful if 19 rows will be returned. But when 62350411 rows will be
> returned, you're talking about a substantial fraction of the table. A
> sequential scan will probably correctly be judged to be faster by the
> planner.
>



pgsql-performance by date:

From: Gaetano Mendola
Date:
Subject: vacuum full, why multiple times ?
From: Aaron Birkland
Date:
Subject: Re: Why would writes to pgsql_tmp bottleneck at 1mb/s?