On Wed, Mar 16, 2005 at 11:20:12PM -0500, Bruce Momjian wrote:
>
> Basically we do open_datasync -> fdatasync -> fsync. This is
> empirically what we found to be fastest on most operating systems, and
> we default to the first one that exists on the operating system.
>
> Notice we never default
Even with Magnus' explanation that we're talking Hardware, and not OS
risk issues, I still think that the default should be the "least risky",
with the other options being well explained from both a risk/performance
standpoint, so that its a conscious decision on the admin's side ...
Any 'risk
Marc G. Fournier wrote:
> On Thu, 17 Mar 2005, Bruce Momjian wrote:
>
> > Dave Page wrote:
> >>> 2. Another question is what to do with 8.0.X? Do we
> >>> backpatch this for
> >>> Win32 performance? Can we test it enough to know it will work well?
> >>> 8.0.2 is going to have a more rigorous te
On Thu, 17 Mar 2005, Bruce Momjian wrote:
Dave Page wrote:
2. Another question is what to do with 8.0.X? Do we
backpatch this for
Win32 performance? Can we test it enough to know it will work well?
8.0.2 is going to have a more rigorous testing cycle because of the
buffer manager changes.
This q
: [HACKERS] Changing the default wal_sync_method
to open_sync for
Considering how stable an Operating System Windows *isn't*
And the last time you ran a 2K/2K3 box was?
Actually, I will get Microsoft credit with their work on XP, I have been
impressed with it ...
Personally, I don'
Dave Page wrote:
> > 2. Another question is what to do with 8.0.X? Do we
> > backpatch this for
> > Win32 performance? Can we test it enough to know it will work well?
> > 8.0.2 is going to have a more rigorous testing cycle because of the
> > buffer manager changes.
>
> This question was ask
> Subject: Re: [HACKERS] Changing the default wal_sync_method
> to open_sync for
>
> Considering how stable an Operating System Windows *isn't*
And the last time you ran a 2K/2K3 box was?
No offence, but my 15 or so servers in that category have had less
downtime in total over the
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> Sent: 17 March 2005 04:20
> To: Magnus Hagander
> Cc: Tom Lane; pgsql-hackers@postgresql.org;
> [EMAIL PROTECTED]; Merlin Moncure
> Subject: [HACKE
> >> I'd like to see this one also considered for 8.0.x, though I'd
> >> certainly like to see some more testing as well. Perhaps it's
> >> suitable for the "8.0.x with extended testing" that is planned for
> >> the ARC replacement code?
> >>
> >> It does make a huge difference on win32. While w
On Wed, 16 Mar 2005, Bruce Momjian wrote:
Magnus Hagander wrote:
I'd like to see this one also considered for 8.0.x, though I'd certainly
like to see some more testing as well. Perhaps it's suitable for the
"8.0.x with extended testing" that is planned for the ARC replacement
code?
It does make a h
Tom Lane wrote:
> Bruce Momjian writes:
> > Notice we never default to open_sync. However, on Win32, Magnus got a
> > 60% speedup by using open_sync, implemented using
> > FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I
> > think we should default to open_sync on Win32. The a
Bruce Momjian writes:
> Notice we never default to open_sync. However, on Win32, Magnus got a
> 60% speedup by using open_sync, implemented using
> FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I
> think we should default to open_sync on Win32. The attached patch
> implements
Magnus Hagander wrote:
> I'd like to see this one also considered for 8.0.x, though I'd certainly
> like to see some more testing as well. Perhaps it's suitable for the
> "8.0.x with extended testing" that is planned for the ARC replacement
> code?
>
> It does make a huge difference on win32. Whil
13 matches
Mail list logo
