On 12.10.2012 09:10, Sergey Konoplev wrote:
> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
The IOS cost depends on other things too. The index can't be read simply
as a sequence of pages, the scan needs to jump around the tree to read
the tuples in the right order.
With the index size being close to the size of the table, the cost of
these operations may easily outweight the benefits. And I suspect this
is the case here, because the table has only 3 columns (INT and two text
ones), and each row has some overhead (header), that may further
decrease the difference between index and table size.
Nevertheless, the cost estimate here is wrong - either it's estimating
something wrong, or maybe everything is in the case and the planner does
not know about that.
Tomas
