See if lowering random_page_cost to 1.5 or so helps here.
That and effective_cache_size are two of the more important values the
planner uses to decide between seq scans and index scans.
On Thu, 29 May 2003, Kevin Schroeder wrote:
> Hello,
> I'm running a simple query on a table and I'm getting a very long
> response time. The table has 56,000 rows in it. It has a full text field,
> but it is not being referenced in this query. The query I'm running is
>
> select row_key, column1, column2, column3, column4, column5 from table1
> where column6 = 1 order by column3 desc limit 21;
>
> There is an index on the table
>
> message_index btree (column6, column3, column7)
>
> Column 3 is a date type, column 6 is an integer and column 7 is unused in
> this query.
>
> The total query time is 6 seconds, but I can bring that down to 4.5 if I
> append "offset 0" to the end of the query. By checking query using "explain
> analyze" it shows that it is using the index.
>
> If anyone has any ideas as to why the query is taking so long and what I can
> do to make it more efficient I would love to know.
>
> Thanks
> Kevin
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>