Skip site navigation (1) Skip section navigation (2)

Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: Curt Sampson <cjs(at)cynic(dot)net>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-04-24 04:38:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 23 Apr 2002, mlw wrote:

> > On a system that has neither read-ahead nor sorting of I/O requests,
> > yes. Which systems are you using that provide neither of these
> > facilities?
> This only happens if the OS can organize the I/O requests in such a manner. It
> is a non-trivial function.

Well, if you call less than 200 lines of code (including lots of
comments), "non-trivial," yes. Have a look at NetBSD's
src/sys/kern/subr_disk.c for one example implementation.

But trivial or not, if all operating systems on which Postgres runs
are doing this, your point is, well, pointless. So, once again, which
systems are you using that do *not* do this?

> > Invariably a process or thread will lose its quantum when it submits
> > an I/O request. (There's nothing left for it to do, since it's waiting
> > for its data to be read, so there's nothing for it to execute.)
> This statement is verifiably false. What a program does after it
> submits an I/O requests is VERY OS and state specific. If an I/O
> request is made for a disk block, which is in read-ahead cache, a
> number of operating systems my return right away.

Sorry, we were working at different levels. You are thinking of
generating an I/O request on the logical level, via a system call.
I was refering to generating a physical I/O request, which a logical
I/O reqeust may or may not do.

So if you would please go back and tackle my argument again, based
on my clarifications above....

Curt Sampson  <cjs(at)cynic(dot)net>   +81 90 7737 2974
    Don't you know, in this new Dark Age, we're all light.  --XTC

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-24 05:40:01
Subject: Re: namedatalen part 2 (cont'd)
Previous:From: Rod TaylorDate: 2002-04-24 03:12:15
Subject: Re: namedatalen part 2 (cont'd)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group