Re: Possible Commit Syntax Change for Improved TPS

Поиск
Список
Период
Сортировка
От seunosewa@inaira.com (Seun Osewa)
Тема Re: Possible Commit Syntax Change for Improved TPS
Дата
Msg-id ba87a3cf.0310020431.366bb6c9@posting.google.com
обсуждение исходный текст
Ответ на Re: Possible Commit Syntax Change for Improved TPS  (Christopher Browne <cbbrowne@acm.org>)
Ответы Re: Possible Commit Syntax Change for Improved TPS  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Список pgsql-hackers
tgl@sss.pgh.pa.us (Tom Lane) wrote in message news:<19310.1064932466@sss.pgh.pa.us>...
> Christopher Browne <cbbrowne@acm.org> writes:
> > In the last exciting episode, seunosewa@inaira.com (Seun Osewa) wrote:
> > So I want to ask, "what if databases have a 'COMMIT NOSYNC;' option?" 
> > Another possibility in this would be to have not one, but TWO
> > backends.  
> > One database, on one port, is running in FSYNC mode, so that the
> > "really vital" stuff is sure to get committed quickly.  The other, on
> > another port, has FSYNC turned off in its postgresql.conf file, and
> > the set of "untrusted" files go there.
> They would have in fact to be two separate installations (not two
> databases under one postmaster).  There is no way to make some
> transactions less safe than others in a single installation, because
> they're all hitting the same WAL log, and potentially modifying the
> same disk buffers to boot.  Anyone's WAL sync therefore syncs everyone's
> changes-so-far.
The beauty of the scheme is that the WAL syncs which "sync everyone's 
changes so far" would cost about the same as the WAL syncs for just 
one transaction being committed.  But when there are so many trans-
actions we would not have to sync the WAL so often.

Seun Osewa


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

Предыдущее
От: seunosewa@inaira.com (Seun Osewa)
Дата:
Сообщение: Dreaming About Redesigning SQL
Следующее
От: Martin Rusoff
Дата:
Сообщение: Parallel postgresql