Re: Running PostgreSQL as fast as possible no matter the consequences

От: Bruce Momjian
Тема: Re: Running PostgreSQL as fast as possible no matter the consequences
Дата: ,
Msg-id: 201101271707.p0RH7eM20612@momjian.us
(см: обсуждение, исходный текст)
Ответ на: Re: Running PostgreSQL as fast as possible no matter the consequences  (Jeff Janes)
Список: pgsql-performance

Скрыть дерево обсуждения

Running PostgreSQL as fast as possible no matter the consequences  (A B, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Thom Brown, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (Thom Brown, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (A B, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Guillaume Cottenceau, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (Marti Raudsepp, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  (Guillaume Cottenceau, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Szymon Guz, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (A B, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  (Marti Raudsepp, )
    Re: Running PostgreSQL as fast as possible no matter the consequences  (Thom Brown, )
    Re: Running PostgreSQL as fast as possible no matter the consequences  (Guillaume Cottenceau, )
     Re: Running PostgreSQL as fast as possible no matter the consequences  (Jon Nelson, )
      Re: Running PostgreSQL as fast as possible no matter the consequences  (Robert Haas, )
       Re: Running PostgreSQL as fast as possible no matter the consequences  (Andy Colson, )
        Re: Running PostgreSQL as fast as possible no matter the consequences  (Robert Haas, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  (Craig Ringer, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  ("Lello, Nick", )
    Re: Running PostgreSQL as fast as possible no matter the consequences  (Dimitri Fontaine, )
    Re: Running PostgreSQL as fast as possible no matter the consequences  (Klaus Ita, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Craig Ringer, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (A B, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Devrim GÜNDÜZ, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (Mladen Gogala, )
 Re: Running PostgreSQL as fast as possible no matter the consequences  (Chris Browne, )
  Re: Running PostgreSQL as fast as possible no matter the consequences  (Bruce Momjian, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  (Fabrízio de Royes Mello, )
   Re: Running PostgreSQL as fast as possible no matter the consequences  (Robert Haas, )
    Re: Running PostgreSQL as fast as possible no matter the consequences  (Bruce Momjian, )
     Re: Running PostgreSQL as fast as possible no matter the consequences  (Jeff Janes, )
      Re: Running PostgreSQL as fast as possible no matter the consequences  (Bruce Momjian, )

Jeff Janes wrote:
> On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian <> wrote:
> > Robert Haas wrote:
> >> On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian <> wrote:
>
> >> > ? ? ? ?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
> >>
> >> This sentence looks to me like it should be removed, or perhaps clarified:
> >>
> >> ? ? This does affect database crash transaction durability.
> >
> > Uh, doesn't it affect database crash transaction durability? ?I have
> > applied the attached patch to clarify things. ?Thanks.
>
> I think the point that was trying to be made there was that the other
> parameters only lose and corrupt data when the machine crashes.
> Synchronous commit turned off will lose data on a mere postgresql
> server crash, it doesn't require a machine-level crash to cause data
> loss.
>
> Indeed, the currently committed doc is quite misleading.
>
> " The following are configuration changes you can make
>     to improve performance in such cases;  they do not invalidate
>     commit guarantees related to database crashes, only abrupt operating
>     system stoppage, except as mentioned below"
>
> We've now removed the thing being mentioned below, but did not remove
> the promise we would be mentioning those things.

Excellent point.  The old wording was just too clever and even I forgot
why I was making that point.  I have updated the docs to clearly state
why this setting is different from the ones above.  Thanks for spotting
this.

Applied patch attached.

--
  Bruce Momjian  <>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 0a10457..1bec5b1 100644
*** a/doc/src/sgml/perform.sgml
--- b/doc/src/sgml/perform.sgml
*************** SELECT * FROM x, y, a, b, c WHERE someth
*** 1157,1165 ****

       <listitem>
        <para>
!        Turn off <xref linkend="guc-synchronous-commit">;  there is no
         need to write the <acronym>WAL</acronym> to disk on every
!        commit.
        </para>
       </listitem>
      </itemizedlist>
--- 1157,1166 ----

       <listitem>
        <para>
!        Turn off <xref linkend="guc-synchronous-commit">;  there might be no
         need to write the <acronym>WAL</acronym> to disk on every
!        commit.  This does enable possible tranaction loss in case of
!        a <emphasis>database</> crash.
        </para>
       </listitem>
      </itemizedlist>


В списке pgsql-performance по дате сообщения:

От: "Kevin Grittner"
Дата:
Сообщение: Re: Postgres 9.0 has a bias against indexes
От: Robert Schnabel
Дата:
Сообщение: How to best use 32 15k.7 300GB drives?