Re: estimated rows vs. actual rows - Mailing list pgsql-performance

From Christopher Browne
Subject Re: estimated rows vs. actual rows
Date
Msg-id m3r7jjpb4m.fsf@knuth.knuth.cbbrowne.com
Whole thread Raw
In response to estimated rows vs. actual rows  (Jaime Casanova <systemguards@gmail.com>)
List pgsql-performance
After takin a swig o' Arrakan spice grog, systemguards@gmail.com (Jaime Casanova) belched out:
> On Sun, 13 Feb 2005 13:41:09 -0800, Josh Berkus <josh@agliodbs.com> 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' || '@' || 'gmail.com';
http://cbbrowne.com/info/emacs.html
When aiming for the common denominator, be prepared for the occasional
division by zero.

pgsql-performance by date:

Previous
From: Harald Fuchs
Date:
Subject: Re: Benchmark
Next
From: Ivan Voras
Date:
Subject: String matching