Re: Dissapearing indexes, what's that all about?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel ?erud <zilch(at)home(dot)se>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Dissapearing indexes, what's that all about?
Date: 2001-04-01 20:48:23
Message-ID: 731.986158103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Daniel ?erud <zilch(at)home(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Tomblin 2001-04-01 21:11:46 Re: Ok, why isn't it using *this* index?
Previous Message ADBAAMD 2001-04-01 20:39:29 Re: Ok, why isn't it using *this* index?