Search Postgresql Archives

Re: why is the LIMIT clause slowing down this SELECT?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2007-08-01 at 21:42 -0500, Mason Hale wrote:
> The score in this case are definitely not a normal distribution. They
> follow a power law pattern, with a few with very high scores and a
> long tail.
> 
> I ended up coercing it to use plan 2 by dropping the index on topic_feed(score).
> 

I think Tom had the correct advice, you should try an index on
(topic_id,score).

> Which raises another question -- if the planner has already used an
> index on topic_id to select the rows, would it ever us another index
> on score to order the rows? Or is a compound topic_feed(topic_id,
> score) index the way to go there?
> 

Two indexes can only be combined for a bitmap index scan, and a bitmap
is in heap order, not index order. That means additional indexes only
help to do additional filtering before it tries to fetch from the table
itself. In your case there is no filter on "score" at all, "score" is
just a sort order.

A compound index should give you what you want.

Regards,
	Jeff Davis


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux