In response to AI Rumman : > I have a table. > > \d email_track > Table "public.email_track" > Column | Type | Modifiers > --------+---------+-------------------- > crmid | integer | not null default 0 > mailid | integer | not null default 0 > count | integer | > Indexes: > "email_track_pkey" PRIMARY KEY, btree (crmid, mailid) CLUSTER > "email_track_count_idx" btree (count) > > > explain analyze select * from email_track where count > 10 ; > QUERY > PLAN > ---------------------------------------------------------------------------------------------------------------------------------------------------- > Bitmap Heap Scan on email_track (cost=12.79..518.05 rows=1941 width=12) > (actual time=0.430..3.047 rows=1743 loops=1) > Recheck Cond: (count > 10) > -> Bitmap Index Scan on email_track_count_idx (cost=0.00..12.79 rows=1941 > width=0) (actual time=0.330..0.330 rows=1743 loops=1) > Index Cond: (count > 10) > Total runtime: 4.702 ms > (5 rows) > > explain analyze select * from email_track where count < 10000 ; > QUERY > PLAN > ---------------------------------------------------------------------------------------------------------------------------------- > Seq Scan on email_track (cost=0.00..1591.65 rows=88851 width=12) (actual time > =0.011..118.499 rows=88852 loops=1) > Filter: (count < 10000) > Total runtime: 201.206 ms > (3 rows) > > I don't know why index scan is not working for count < 10000 operation. > Any idea please. How many rows contains the table? I think, with your where-condition count < 10000 roughly the whole table in the result, right? In this case, a seq-scan is cheaper than an index-scan. Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
