On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian br...@momjian.us 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:
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, packets,
On Mon, Jun 28, 2010 at 1:12 PM, Craig James craig_ja...@emolecules.com 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
Robert Haas wrote:
On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
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]
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 postgresql
On Tue, Jun 29, 2010 at 9:32 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian br...@momjian.us wrote:
The patch also documents that synchronous_commit = false has
potential committed transaction loss from a database crash (as well as
Robert Haas wrote:
On Tue, Jun 29, 2010 at 9:32 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Jun 28, 2010 at 5:57 PM, Bruce Momjian br...@momjian.us wrote:
The patch also documents that synchronous_commit = false has
potential committed transaction loss from a
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
Samuel Gendler sgend...@ideasculptor.com 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
On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
Jignesh Shah wrote:
On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
16 matches
Mail list logo
