Re: Experimental patch for inter-page delay in VACUUM

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ang Chin Han <angch(at)bytecraft(dot)com(dot)my>, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-10 14:25:53
Message-ID: 3FAF9FF1.1010005@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

What bothers me a little is that you keep telling us that you have all
that great code from SRA. Do you have any idea when they intend to share
this with us and contribute the stuff? I mean at least some pieces
maybe? You personally got all the code from NuSphere AKA PeerDirect even
weeks before it got released. Did any PostgreSQL developer other than
you ever look at the SRA code?

Jan

Bruce Momjian wrote:

> scott.marlowe wrote:
>> On Tue, 4 Nov 2003, Tom Lane wrote:
>>
>> > Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>> > > What still needs to be addressed is the IO storm cause by checkpoints. I
>> > > see it much relaxed when stretching out the BufferSync() over most of
>> > > the time until the next one should occur. But the kernel sync at it's
>> > > end still pushes the system hard against the wall.
>> >
>> > I have never been happy with the fact that we use sync(2) at all. Quite
>> > aside from the "I/O storm" issue, sync() is really an unsafe way to do a
>> > checkpoint, because there is no way to be certain when it is done. And
>> > on top of that, it does too much, because it forces syncing of files
>> > unrelated to Postgres.
>> >
>> > I would like to see us go over to fsync, or some other technique that
>> > gives more certainty about when the write has occurred. There might be
>> > some scope that way to allow stretching out the I/O, too.
>> >
>> > The main problem with this is knowing which files need to be fsync'd.
>>
>> Wasn't this a problem that the win32 port had to solve by keeping a list
>> of all files that need fsyncing since Windows doesn't do sync() in the
>> classical sense? If so, then could we use that code to keep track of the
>> files that need fsyncing?
>
> Yes, I have that code from SRA. They used threading, so they recorded
> all the open files in local memory and opened/fsync/closed them for
> checkpoints. We have to store the file names in a shared area, perhaps
> an area of shared memory with an overflow to a disk file.
>

--
#======================================================================#
# 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 #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-11-10 14:26:38 Re: Experimental patch for inter-page delay in VACUUM
Previous Message Bruce Momjian 2003-11-10 14:25:49 Re: Experimental patch for inter-page delay in VACUUM