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

От: Andy Colson
Тема: Re: Running PostgreSQL as fast as possible no matter the consequences
Дата: ,
Msg-id: 4CE189AF.6020308@squeakycode.net
(см: обсуждение, исходный текст)
Ответ на: Re: Running PostgreSQL as fast as possible no matter the consequences  (Robert Haas)
Ответы: Re: Running PostgreSQL as fast as possible no matter the consequences  (Robert Haas)
Список: 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, )

On 11/15/2010 9:06 AM, Robert Haas wrote:
> In 9.1, I'm hopeful that we'll have unlogged tables, which will even
> better than turning these parameters off, and for which I just posted
> a patch to -hackers.  Instead of generating WAL and writing WAL to the
> OS and then NOT trying to make sure it hits the disk, we just won't
> generate it in the first place.  But if PostgreSQL or the machine it's
> running on crashes, you won't need to completely blow away the cluster
> and start over; instead, the particular tables that you chose to
> create as unlogged will be truncated, and the rest of your data,
> including the system catalogs, will still be intact.
>

if I am reading this right means: we can run our db safely (with fsync
and full_page_writes enabled) except for tables of our choosing?

If so, I am very +1 for this!

-Andy


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

От: Artur Zając
Дата:
Сообщение: Re: Difference between explain analyze and real execution time
От: Humair Mohammed
Дата:
Сообщение: