Jan Wieck wrote: > Bruce Momjian wrote: > > > 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 process limitations (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? > > > > As said, not using fsync() but sync() at that place. This only makes a > real difference when you're not running PostgreSQL on a dedicated > server. And yes, it really works well.
I talked to Jan about this. Basically, for testing, if sync decreases the checkpoint load, fsync/O_SYNC should do even better, hopefully, once he has that implemented. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
