Re: Read/Write block sizes

Список
Период
Сортировка
От Jeffrey W. Baker
Тема Re: Read/Write block sizes
Дата
Msg-id 1124861121.11270.1.camel@noodles
обсуждение исходный текст
Ответ на Re: Read/Write block sizes  (Guy Thornley)
Ответы Re: Read/Write block sizes  (Tom Lane)
Список 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, )
On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
> As for the async IO, sure you might think 'oh async IO would be so cool!!'
> and I did, once, too. But then I sat down and _thought_ about it, and
> decided well, no, actually, theres _very_ few areas it could actually help,
> and in most cases it just make it easier to drive your box into lseek()
> induced IO collapse.
>
> 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.

-jwb


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

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