Indicies work on FreeBSD, not on Linux - Mailing list pgsql-hackers

From Christopher Farley
Subject Indicies work on FreeBSD, not on Linux
Date
Msg-id 20050305081836.GA21744@northernbrewer.com
Whole thread Raw
Responses Re: Indicies work on FreeBSD, not on Linux
List pgsql-hackers
I'm sure this is something simple, but my Linux development machine
running Postgresql 7.4.7 has very different behavior than my FreeBSD
production machine running Postgresql 7.4.2. I've got the same table
definitions, but I do have different data in the databases.

On FreeBSD, indicies do what I expect they would -- everything speeds up
nice and 'explain analyze' shows me that an index scan is happening.

On my Linux machine, the CREATE INDEX statement works, and I can see
the index when I view the table information. But 'explain analyze'
indicates that a sequential scan is still occuring.

Any ideas? 

############ FREEBSD BEFORE & AFTER INDEXING ###############

freebsd=# explain analyze select * from orders where or_status = 'N';
QUERYPLAN 
 
-------------------------------------------------------------------------------------------------------------Seq Scan
onorders  (cost=0.00..2590.03 rows=47 width=759) (actual
 
time=6029.894..6090.079 rows=38 loops=1)  Filter: (or_status = 'N'::bpchar)Total runtime: 6090.476 ms
(3 rows)

freebsd=# create index or_status_idx on orders(or_status);
CREATE INDEX
freebsd=# explain analyze select * from orders where or_status = 'N';
    QUERY PLAN 
 

----------------------------------------------------------------------------------------------------------------------------Index
Scanusing or_status_idx on orders  (cost=0.00..382.26 rows=96
 
width=759) (actual time=0.098..1.648 rows=38 loops=1)  Index Cond: (or_status = 'N'::bpchar)Total runtime: 1.866 ms
(3 rows)


############ LINUX BEFORE & AFTER INDEXING ###############

linux=# explain analyze select * from orders where or_status = 'N' order
by or_number;                                                   QUERY PLAN 
-------------------------------------------------------------------------------------------------------------------Sort
(cost=3978.80..3985.74 rows=2776 width=770) (actual
 
time=1304.325..1351.477 rows=7760 loops=1)  Sort Key: or_number  ->  Seq Scan on orders  (cost=0.00..3260.35 rows=2776
width=770)
(actual time=0.192..869.504 rows=7760 loops=1)        Filter: (or_status = 'N'::bpchar)Total runtime: 1361.277 ms
(5 rows)

linux=# create index or_status_idx on orders(or_status);
CREATE INDEX
linux=# explain analyze select * from orders where or_status = 'N' order
by or_number;                                                   QUERY PLAN 
-------------------------------------------------------------------------------------------------------------------Sort
(cost=3981.40..3988.35 rows=2779 width=770) (actual
 
time=1338.112..1384.465 rows=7760 loops=1)  Sort Key: or_number  ->  Seq Scan on orders  (cost=0.00..3260.54 rows=2779
width=770)
(actual time=0.185..891.342 rows=7760 loops=1)        Filter: (or_status = 'N'::bpchar)Total runtime: 1394.538 ms
(5 rows)


-- 
Christopher Farley
www.northernbrewer.com


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Best practices: MERGE
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Best practices: MERGE