On 2008-02-12 13:35, Pallav Kalva wrote:
Hi,
...
Table Definitions
============
\d listing.listingstatus
Table "listing.listingstatus"
Column | Type
| Modifiers
-----------------+-----------------------------+------------------------------------------------------------------------
listingstatusid | integer | not null default
nextval(('listing.listingstatusseq'::text)::regclass)
shortname | text |
longname | text |
_entrydate | timestamp without time zone | default
('now'::text)::timestamp(6) without time zone
Indexes:
"pk_listingstatus_listingstatusid" PRIMARY KEY, btree
(listingstatusid), tablespace "indexdata"
Since you are searching by "shortname", trying adding an index on that.
Although with that tiny a table, it might not matter.
The questions are:
1. Why in the planner scanning the entire idx_listing_entrydate, when
I'd think it should be scanning the entire
pk_listingstatus_listingstatusid ?
2. Why is "Index Scan using pk_listingstatus_listingstatusid on
listingstatus listingsta1_ (cost=0.00..0.27 rows=1 width=4) (never
executed)" ?
Note: I'm new at this as well, and jumped in to learn as well as to help.
-- Dean
--
Mail to my list address MUST be sent via the mailing list. All other mail will bounce.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
