After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Jaime Casanova) 
belched out:
> On Sun, 13 Feb 2005 13:41:09 -0800, Josh Berkus <> wrote:
>> Jaime,
>> > Why is this query using a seq scan rather than a index scan?
>> Because it thinks a seq scan will be faster.
> I will suggest him to probe with seq scans disabled.
> But, IMHO, if the table has 143902 and it thinks will retrieve 2610
> (almost 1.81% of the total). it won't be faster with an index?

If the 2610 rows are scattered widely enough, it may be cheaper to do
a seq scan.

After all, with a seq scan, you read each block of the table's pages
exactly once.

With an index scan, you read index pages _and_ table pages, and may do
and redo some of the pages.

It sounds as though it's worth forcing the matter and trying it both
ways and comparing them.  Don't be surprised if the seq scan is in
fact faster...
select 'cbbrowne' || '@' || '';
When aiming for the common denominator, be prepared for the occasional
division by zero.

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

Reply via email to