Re: Inserts optimization?

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Inserts optimization?
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA352AE@algol.sollentuna.se
обсуждение исходный текст
Ответ на Inserts optimization?  (Francisco Reyes <lists@stringsutils.com>)
Ответы Re: Inserts optimization?  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: Inserts optimization?  (Markus Schaber <schabi@logix-tt.com>)
Список pgsql-performance
> > For now, I only could get good performance with bacula and
> postgresql
> > when disabling fsync...
>
>
> Isn't that less safe?

Most definitly.

FWIW, I'm getting pretty good speeds with Bacula and PostgreSQL on a
reasonably small db (file table about 40 million rows, filename about
5.2 million and path 1.5 million).

Config changes are increasing shared mem and work mems, fsm pages,
wal_sync_method=fdatasync, wal_buffers=16, checkpoint_segments=8,
default_with_oids=off (before creating the bacula tables, so they don't
use oids).

Used to run with full_pages_writes=off, but not anymore since it's not
safe.


> Also planning to check commit_delay and see if that helps.
> I will try to avoid 2 or more machines backing up at the same
> time.. plus in a couple of weeks I should have a better
> machine for the DB anyways..

Bacula already serializes access to the database (they have to support
mysql/myisam), so this shouldn't help. Actually, it might well hurt by
introducing extra delays.

> I only wonder what is safer.. using a second or two in
> commit_delay or using
> fsync = off.. Anyone cares to comment?

Absolutely a commit_delay.


//Magnus

В списке pgsql-performance по дате отправления:

Предыдущее
От: Markus Schaber
Дата:
Сообщение: Re: merge>hash>loop
Следующее
От: Mario Splivalo
Дата:
Сообщение: SELECT FOR UPDATE performance is bad