Re: pgsql-server/src backend/storage/buffer/bufmgr ...
От | Jan Wieck |
---|---|
Тема | Re: pgsql-server/src backend/storage/buffer/bufmgr ... |
Дата | |
Msg-id | 4016F05A.7060602@Yahoo.com обсуждение исходный текст |
Ответ на | Re: pgsql-server/src backend/storage/buffer/bufmgr ... (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: pgsql-server/src backend/storage/buffer/bufmgr ...
|
Список | pgsql-committers |
Bruce Momjian wrote: > I guess my major problem with moving away from sync is similar to the > reason we don't do raw devices --- sync is best done in the kernel and > disk driver that knows more about how to do it efficiently. I haven't > see any non-sync solution with performance similar to sync(). However, > we are going to have to write one for win32, so we can test things once > we are done and then decide. We are not doing raw devices because we don't do tablespaces. I mean in the method where a tablespace for the OS is basically a huge container. For every little table, PostgreSQL creates a separate file and scatters the data all over the place because it is too dumb to group allocations of multiple blocks together. As a consequence, it is short of file descriptors and needs the kernel at least to reorder it's write requests so that they are not done in the clueless order they are issued. Now doing fsync() or fdatasync() of possibly dozens of files in a row, forcing the kernel to do one scattered file after another, letting the disk heads dance like step-chicken on a hot tin ... that will be an improvement, oh boy. However safe this will be, nobody will use it because MySQL is soooo much faster! Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-committers по дате отправления: