From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-11-10 18:02:26 |
Message-ID: | 3FAFD2B2.30001@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-11-10 18:12:29 | Re: [HACKERS] Changes to Contributor List |
Previous Message | Larry Rosenman | 2003-11-10 17:57:35 | Re: Experimental patch for inter-page delay in VACUUM |