Jignesh Shah wrote:
> On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> >>> I asked on IRC and was told it is true, and looking at the C code it
> >> >>> looks true. ?What synchronous_commit = false does is to delay writing
> >> >>> the wal
Craig James wrote:
synchronous_commit = off
full_page_writes = off
I don't have any numbers handy on how much turning synchronous_commit
and full_page_writes off improves performance on a system with a
battery-backed write cache. Your numbers are therefore a bit inflated
against similar one
On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> >>> I asked on IRC and was told it is true, and looking at the C code it
>> >>> looks true. ?What synchronous_commit = false does is to delay writing
>> >>> the wal buffers to disk and fsyncing the
Samuel Gendler wrote:
> queries are definitely taking longer than we'd like them to
> Database currently occupies 91GB on disk.
> I get no resistance when I suggest going to 64GB of RAM.
One thing that jumps out at me is that with a 91GB database, and no
pushback on buying 64GB of RAM, it
I've been reading this list for a couple of weeks, so I've got some
sense of what you folks are likely to recommend, but I'm curious what
is considered an ideal storage solution if building a database system
from scratch. I just got an exploratory call from my boss, asking
what my preference would
Tom Lane wrote:
> Bruce Momjian writes:
> >>> I asked on IRC and was told it is true, and looking at the C code it
> >>> looks true. ?What synchronous_commit = false does is to delay writing
> >>> the wal buffers to disk and fsyncing them, not just fsync, which is
> >>> where the commit loss due t
Bruce Momjian writes:
>>> I asked on IRC and was told it is true, and looking at the C code it
>>> looks true. ?What synchronous_commit = false does is to delay writing
>>> the wal buffers to disk and fsyncing them, not just fsync, which is
>>> where the commit loss due to db process crash comes f
Robert Haas wrote:
> On Tue, Jun 29, 2010 at 9:32 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian wrote:
> >> >> The patch also documents that synchronous_commit = false has
> >> >> potential committed transaction loss from a database crash (as
On Tue, Jun 29, 2010 at 9:32 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian wrote:
>> >> The patch also documents that synchronous_commit = false has
>> >> potential committed transaction loss from a database crash (as well as
>> >> an OS crash).
>
Benjamin Krajmalnik wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:br...@momjian.us]
> > Sent: Monday, June 28, 2010 3:45 PM
> > To: Benjamin Krajmalnik
> > Cc: Rajesh Kumar Mallah; Kevin Grittner; pgsql-
> > performa...@postgresql.org
> > Subject: Re: [PERFORM] cpu bound pos
Bruce,
Unfortunately not. The behavior I had was ebbs and flows. On FreeBSD,
I was seeing a lot of kernel wait states in top. So every few minutes,
responsiveness of the db was pretty bad. 8.4.4/amd64 on FreeBSD 7.2
> -Original Message-
> From: Bruce Momjian [mailto:br...@momjian.us]
>
Bruce Momjian wrote:
> What synchronous_commit = false does is to delay writing
> the wal buffers to disk and fsyncing them, not just fsync
Ah, that answers the question Josh Berkus asked here:
http://archives.postgresql.org/pgsql-performance/2010-06/msg00285.php
(which is something I was
Robert Haas wrote:
> On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian wrote:
> >> The patch also documents that synchronous_commit = false has
> >> potential committed transaction loss from a database crash (as well as
> >> an OS crash).
>
> Is this actually true?
I asked on IRC and was told it is
On Mon, Jun 28, 2010 at 1:12 PM, Craig James wrote:
> On 6/25/10 12:03 PM, Greg Smith wrote:
>>
>> Craig James wrote:
>>>
>>> I've got a new server and want to make sure it's running well.
>>
>> Any changes to the postgresql.conf file? Generally you need at least a
>> moderate shared_buffers (1GB
Hi,
One more question about two specifics query behavior: If I add "AND (ip_dst
= x.x.x.x)", it uses another plan and take a much more time. In both of
them, I'm using WHERE clause. Why this behavior?
=> explain analyze SELECT ip_src, port_src, ip_dst, port_dst, tcp_flags,
ip_proto, bytes, packet
On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian wrote:
>> The patch also documents that synchronous_commit = false has
>> potential committed transaction loss from a database crash (as well as
>> an OS crash).
Is this actually true?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
16 matches
Mail list logo
