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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
