From: | DeJuan Jackson <djackson(at)speedfc(dot)com> |
---|---|
To: | Tim McAuley <mcauleyt(at)tcd(dot)ie> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Unused Indexes |
Date: | 2003-07-30 13:26:40 |
Message-ID: | 3F27C790.2030409@speedfc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Assuming you have done a 'VACUUM ANALYZE' on the table in question you
are most likely running into a type coercion issue.
So explicitly cast your constants to bigint and the index should start
being considered.
select id from <table> where col2 = 1::bigint and col2 = 1::bigint
Tim McAuley wrote:
> Hi,
>
> I have a table which I have populated with over 5000 entries. There is
> a combined index placed on two of the columns (both bigint). I am
> trying a simple select (i.e. select id where col1 = 1 and col2 = 1)
> covering these two columns and it keeps using a seq scan. Is this
> correct? I would have thought that with this number of entries that an
> index scan should be used.
>
> I am testing this using postgresql 7.3.3 on windows 2000 using cygwin.
>
> Doing "set enable_seqscan to off" does not change the results of the
> explain operation.
>
> I also tried setting a single index on just one of the columns and
> running an appropriate search; it still uses a seq scan. At what stage
> will the planner normally start using an index scan?
>
> Any hints appreciated.
>
> Tim
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Murtagh | 2003-07-30 13:30:06 | Changing DB ownership |
Previous Message | DeJuan Jackson | 2003-07-30 13:20:32 | Re: SQL SUM query limited by dates |