Re: Experimental patch for inter-page delay in VACUUM
От | Bruce Momjian |
---|---|
Тема | Re: Experimental patch for inter-page delay in VACUUM |
Дата | |
Msg-id | 200311101905.hAAJ5bk24142@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Experimental patch for inter-page delay in VACUUM (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Experimental patch for inter-page delay in VACUUM
|
Список | pgsql-hackers |
Jan Wieck wrote: > Zeugswetter Andreas SB SD wrote: > > >> > One problem with O_SYNC would be, that the OS does not group writes any > >> > more. So the code would need to eighter do it's own sorting and grouping > >> > (256k) or use aio, or you won't be able to get the maximum out of the disks. > >> > >> Or just run multiple writer processes, which I believe is Oracle's > >> solution. > > > > That does not help, since for O_SYNC the OS'es (those I know) do not group those > > writes together. Oracle allows more than one writer to busy more than one disk(subsystem) and circumvent other per processlimitations (mainly on platforms without AIO). > > Yes, I think the best way would be to let the background process write a > bunch of pages, then fsync() the files written to. If one tends to have > many dirty buffers to the same file, this will group them together and > the OS can optimize that. If one really has completely random access, > then there is nothing to group. Agreed. This might force enough stuff out to disk the checkpoint/sync() would be OK. Jan, have you tested this? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: