From: | "Dean Gibson (DB Administrator)" <postgresql(at)ultimeth(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Optimizing No matching record Queries |
Date: | 2008-02-13 00:07:29 |
Message-ID: | 47B234C1.1090707@ultimeth.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-02-13 00:16:44 | Re: Optimizing No matching record Queries |
Previous Message | Stephen Denne | 2008-02-12 22:09:29 | Re: Optimizing No matching record Queries |