Re: Index Scans become Seq Scans after VACUUM ANALYSE

Поиск
Список
Период
Сортировка
От mlw
Тема Re: Index Scans become Seq Scans after VACUUM ANALYSE
Дата
Msg-id 3CC62042.B00A70A1@mohawksoft.com
обсуждение исходный текст
Ответ на Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Curt Sampson <cjs@cynic.net>)
Ответы Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Curt Sampson <cjs@cynic.net>)
Список pgsql-hackers
Curt Sampson wrote:
> 
> On Thu, 18 Apr 2002, Michael Loftis wrote:
> 
> > mlw wrote:
> >
> > >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.
> 
> 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.

> 
> > In a multi-tasking system it's always cheaper to fetch less blocks, no
> > matter where they are.  Because, as you said, it will end up more or
> > less random onf a system experiencing a larger number of queries.
> 
> 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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: mlw
Дата:
Сообщение: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Следующее
От: "Rod Taylor"
Дата:
Сообщение: Re: namedatalen part 2 (cont'd)