Re: estimated rows vs. actual rows

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: estimated rows vs. actual rows
Date: 2005-02-14 12:41:13
Message-ID: m3r7jjpb4m.fsf@knuth.knuth.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

After takin a swig o' Arrakan spice grog, systemguards(at)gmail(dot)com (Jaime Casanova) belched out:
> On Sun, 13 Feb 2005 13:41:09 -0800, Josh Berkus <josh(at)agliodbs(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ivan Voras 2005-02-14 19:57:27 String matching
Previous Message Harald Fuchs 2005-02-14 10:46:18 Re: Benchmark