RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
От | Mikheev, Vadim |
---|---|
Тема | RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D3187@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответы |
Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Список | pgsql-hackers |
> > BUT, do we know for sure that sleep(0) is not optimized in > > the library to just return? > > We can only do our best here. I think guessing whether other backends > are _about_ to commit is pretty shaky, and sleeping every time is a > waste. This seems the cleanest. A long ago you, Bruce, made me gift - book about transaction processing (thanks again -:)). This sleeping before fsync in commit is described there as standard technique. And the reason is cleanest. Men, cost of fsync is very high! { write (64 bytes) + fsync() } takes ~ 1/50 sec. Yes, additional 1/200 sec or so results in worse performance when there is only one backend running but greatly increase overall performance for 100 simultaneous backends. Ie this delay is trade off to gain better scalability. I agreed that it must be configurable, smaller or probably 0 by default, use approximate # of simultaneously running backends for guessing (postmaster could maintain this number in shmem and backends could just read it without any locking - exact number is not required), good described as tuning patameter in documentation. Anyway I object sleep(0). Vadim
В списке pgsql-hackers по дате отправления: