From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Date: | 2002-04-17 21:44:13 |
Message-ID: | 3CBDECAD.28F2D897@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> My second point, that index scan is more risky than sequential scan, is
> outlined above. A sequential scan reads each page once, and uses the
> file system read-ahead code to prefetch the disk buffers. Index scans
> are random, and could easily re-read disk pages to plow through a
> significant portion of the table, and because the reads are random,
> the file system will not prefetch the rows so the index scan will have
> to wait for each non-cache-resident row to come in from disk.
It took a bike ride to think about this one. The supposed advantage of a
sequential read over an random read, in an active multitasking system, is a
myth. If you are executing one query and the system is doing only that query,
you may be right.
Execute a number of queries at the same time, the expected benefit of a
sequential scan goes out the window. The OS will be fetching blocks, more or
less, at random.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-17 21:54:21 | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Previous Message | Bruce Momjian | 2002-04-17 21:41:43 | Re: Index Scans become Seq Scans after VACUUM ANALYSE |