Re: improving concurrent transactin commit rate
От | Greg Stark |
---|---|
Тема | Re: improving concurrent transactin commit rate |
Дата | |
Msg-id | 8CB39400-4491-4353-903D-D20A215007EF@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: improving concurrent transactin commit rate (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Sorry for top-posting -- blame apple. Isn't this just a good description of exactly how it works today? -- Greg On 24 Mar 2009, at 20:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Sam Mason <sam@samason.me.uk> writes: >> The conceptual idea is to have at most one outstanding flush for the >> log going through the filesystem at any one time. > > I think this is a variant of the "group commit" or "commit delay" > stuff that's already in there (and doesn't work real well :-(). > The problem is to sync multiple transactions without a lot of extra > overhead. > > Realize also that if the kernel's not completely brain dead, some > of this happens already by virtue of the fact that everyone's > fsync'ing the same WAL file. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: