Postgres Professional
en

Re: Read/Write block sizes

От: Tom Lane
Тема: Re: Read/Write block sizes
Дата: ,
Msg-id: 21700.1124863004@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Read/Write block sizes  ("Jeffrey W. Baker")
Ответы: Re: Read/Write block sizes  ("Jeffrey W. Baker")
Re: Read/Write block sizes  (PFC)
Список: pgsql-performance

Скрыть дерево обсуждения

Re: Read/Write block sizes (Was: Caching by Postgres)  (Jignesh Shah, )
 Re: Read/Write block sizes  (Chris Browne, )
  Re: Read/Write block sizes  (Michael Stone, )
  Re: Read/Write block sizes  ("Jim C. Nasby", )
   Re: Read/Write block sizes  ("Jignesh K. Shah", )
    Re: Read/Write block sizes  (Bruce Momjian, )
  Re: Read/Write block sizes  (Steve Poe, )
   Re: Read/Write block sizes  (Josh Berkus, )
    Re: Read/Write block sizes  (Alan Stange, )
    Re: Read/Write block sizes  ("Jeffrey W. Baker", )
     Re: Read/Write block sizes  (Tom Lane, )
      Re: Read/Write block sizes  (Josh Berkus, )
     Re: Read/Write block sizes  (Guy Thornley, )
      Re: Read/Write block sizes  ("Jeffrey W. Baker", )
       Re: Read/Write block sizes  (Tom Lane, )
        Re: Read/Write block sizes  ("Jeffrey W. Baker", )
         Re: Read/Write block sizes  (Josh Berkus, )
          Re: Read/Write block sizes  (Ron, )
        Re: Read/Write block sizes  (PFC, )
 Re: Read/Write block sizes (Was: Caching by Postgres)  (Michael Stone, )
  Re: Read/Write block sizes (Was: Caching by Postgres)  ("Jeffrey W. Baker", )
 Re: Read/Write block sizes  (Chris Browne, )
  Re: Read/Write block sizes  ("Jim C. Nasby", )
 Re: Read/Write block sizes  (Chris Browne, )
  Re: Read/Write block sizes  (Ron, ) 
"Jeffrey W. Baker" <> writes:
> On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
>> Dont forget that already in postgres, you have a process per connection, and
>> all the processes take care of their own I/O.

> That's the problem.  Instead you want 1 or 4 or 10 i/o slaves
> coordinating the I/O of all the backends optimally.  For instance, with
> synchronous scanning.

And why exactly are we going to do a better job of I/O scheduling than
the OS itself can do?

There's a fairly basic disconnect in viewpoint involved here.  The
old-school viewpoint (as embodied in Oracle and a few other DBMSes)
is that the OS is too stupid to be worth anything, and the DB should
bypass the OS to the greatest extent possible, doing its own caching,
disk space layout, I/O scheduling, yadda yadda.  That might have been
defensible twenty-odd years ago when Oracle was designed.  Postgres
prefers to lay off to the OS anything that the OS can do well --- and
that definitely includes caching and I/O scheduling.  There are a whole
lot of smart people working on those problems at the OS level.  Maybe we
could make marginal improvements on their results after spending a lot
of effort reinventing the wheel ... but our time will be repaid much
more if we work at levels that the OS cannot have knowledge of, such as
join planning and data statistics.

There are some things we could do to reduce the impedance between us and
the OS --- for instance, the upthread criticism that a seqscan asks the
OS for only 8K at a time is fair enough.  But that doesn't translate
to a conclusion that we should schedule the I/O instead of the OS.

            regards, tom lane

В списке pgsql-performance по дате сообщения:

Предыдущее:
От: PFC
Дата:
Сообщение: Re: Read/Write block sizes
Следующее:
От: Donald Courtney
Дата:
Сообщение: Re: Caching by Postgres