Re: Dissapearing indexes, what's that all about? - Mailing list pgsql-general

From Tom Lane
Subject Re: Dissapearing indexes, what's that all about?
Date
Msg-id 731.986158103@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Dissapearing indexes, what's that all about?  (Daniel ?erud <zilch@home.se>)
List pgsql-general
Daniel ?erud <zilch@home.se> writes:
> Can't see the logic behind that though
> The jump in the b-tree must save about 5000 checks... half
> the table??

CPUs are fast.  Disks are slow.  If you think about CPU time rather
than disk accesses, you will usually draw the wrong conclusions.

Even more to the point, disks do not like random access.  A seqscan
can typically fetch four or more sequential blocks from disk in the
time it takes an indexscan to fetch one block on a random-access basis.

When you do the math it turns out seqscan wins unless you are fetching
just a small percentage of the rows.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: another index question
Next
From: "ADBAAMD"
Date:
Subject: Re: Ok, why isn't it using *this* index?