Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Perhaps make them emit a WARNING at server start or something.
I concur with Greg Stark's earlier comment that this is all
overreaction. Let's just fix the misleading comment in the
documentation and leave it at that.
regards,
Tom Lane escribió:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > ... I didn't think this was a big problem because I
> > thought it was limited to developers who shot their own foot, but if there
> > are packagers turning this on to improve beta feedback it deserves some
> > wider mention.
>
>
"Greg Smith" <[EMAIL PROTECTED]> writes:
> The worst time people can run into a performance
> regression is when they're running a popular benchmarking tool.
Hm, perhaps pg_bench should do a "show debug_assertions" and print a warning
if the answer isn't "off". We could encourage other benchmar
In response to Mark Mielke <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > In response to Mark Mielke <[EMAIL PROTECTED]>:
> >
> >
> >> Bill Moran wrote:
> >>
> >>> I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing
> >>> consistency checking at that point.
> >>>
On Dec 26, 2007, at 4:28 PM, [EMAIL PROTECTED] wrote:
now, if you can afford solid-state drives which don't have noticable
seek times, things are completely different ;-)
Who makes one with "infinite" lifetime? The only ones I know of are
built using RAM and have disk drive backup with in
On Dec 26, 2007, at 10:21 AM, Bill Moran wrote:
I snipped the rest of your message because none of it matters.
Never use
RAID 5 on a database system. Ever. There is absolutely NO reason to
every put yourself through that much suffering. If you hate yourself
that much just commit suicide,
Shane Ambler wrote:
>> I achieve something closer to +20% - +60% over the theoretical
>> performance of a single disk with my four disk RAID 1+0 partitions.
>
> If a good 4 disk SATA RAID 1+0 can achieve 60% more throughput than a
> single SATA disk, what sort of percentage can be achieved from
Greg Smith <[EMAIL PROTECTED]> writes:
> ... I didn't think this was a big problem because I
> thought it was limited to developers who shot their own foot, but if there
> are packagers turning this on to improve beta feedback it deserves some
> wider mention.
Yeah, binary packages that are bu
On Thu, 27 Dec 2007, Gregory Stark wrote:
Fwiw I think you're all getting a bit caught up in this one context.
I lost a day once over this problem. Guillaume lost at least that much.
Sounds like Magnus and Dave got a good sized dose as well. Seems like
something worth warning people about
Bill Moran wrote:
In response to Mark Mielke <[EMAIL PROTECTED]>:
Bill Moran wrote:
I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing
consistency checking at that point.
According to this:
http://www.freebsd.org/cgi/man.cgi?query=gmirror&apropos=0&sekt
On Thu, Dec 27, 2007 at 01:14:25PM +, Gregory Stark wrote:
> "Jared Mauch" <[EMAIL PROTECTED]> writes:
>
> > pg_dump is utilizing about 13% of the cpu and the
> > corresponding postgres backend is at 100% cpu time.
> > (multi-core, multi-cpu, lotsa ram, super-fast disk).
> >...
> > pg8
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>
>> Currently the docs say that --enable-cassert
>>
>> Enables assertion checks in the server, which test for
>> many cannot happen conditions. This is invaluable for
>> code development purposes, but t
In response to Mark Mielke <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> >
> >> What do you mean "heard of"? Which raid system do you know of that reads
> >> all drives for RAID 1?
> >>
> >
> > I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing
> > consistency checking a
Tom Lane escribió:
> Currently the docs say that --enable-cassert
>
> Enables assertion checks in the server, which test for
> many cannot happen conditions. This is invaluable for
> code development purposes, but the tests slow things down a little.
>
> Maybe we ough
"Jared Mauch" <[EMAIL PROTECTED]> writes:
> pg_dump is utilizing about 13% of the cpu and the
> corresponding postgres backend is at 100% cpu time.
> (multi-core, multi-cpu, lotsa ram, super-fast disk).
>...
> pg8.3(beta) with the following variances from default
>
> checkpoint_segment
On Thu, Dec 27, 2007 at 01:10:29AM -0500, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Wed, 26 Dec 2007, Guillaume Smet wrote:
> >> beta RPMs are by default compiled with --enable-debug and
> >> --enable-cassert which doesn't help them to fly fast...
>
> > Got that right. Last
On Dec 27, 2007 7:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Enables assertion checks in the server, which test for
> many cannot happen conditions. This is invaluable for
> code development purposes, but the tests slow things down a little.
>
> Maybe we ought to put t
17 matches
Mail list logo
