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: Pine.NEB.4.43.0204241325310.439-100000@angelic.cynic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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....

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

In response to

Responses

Browse pgsql-hackers by date

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