Re: Read/Write block sizes

От: PFC
Тема: Re: Read/Write block sizes
Дата: ,
Msg-id: op.sv0c0u1cth1vuj@localhost
(см: обсуждение, исходный текст)
Ответ на: 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, )

> 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.

    Considering a global budget of man-hours which is the best ?

1- Spend it on reimplementing half of VFS in postgres, half of Windows in
postgres, half of FreeBSD in postgres, half of Solaris in Postgres, only
to discover you gain a meagre speed increase and a million and a half bugs,

2- Spending 5% of that time lowering the impedance between the OS and
Postgres, and another 5% annoying Kernel people and helping them tweaking
stuff for database use, and the rest on useful features that give useful
speedups, like bitmap indexes, skip scans, and other features that enhance
power and usability ?

If you're Oracle and have almost unlimited resources, maybe. But even
Microsoft opted for option 2 : they implemented ReadFileGather and
WriteFileScatter to lower the syscall overhead and that's it.

And point 2 will benefit to many other apps, wether 1 would benefit only
postgres, and then only in certain cases.

I do believe there is something ineresting to uncover with reiser4 though
(it definitely fits point 2).

I'm happy that the pg team chose point 2 and that new versions keep coming
with new features at an unbelievable rate these times. Do you guys sleep ?


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

От: Arjen van der Meijden
Дата:
Сообщение: Re: performance drop on RAID5
От: Chris Browne
Дата:
Сообщение: Re: Read/Write block sizes