Re: SetBufferCommitInfoNeedsSave and race conditions
От | Gregory Stark |
---|---|
Тема | Re: SetBufferCommitInfoNeedsSave and race conditions |
Дата | |
Msg-id | 871wfnwa0x.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: SetBufferCommitInfoNeedsSave and race conditions ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: SetBufferCommitInfoNeedsSave and race
conditions
|
Список | pgsql-hackers |
"Simon Riggs" <simon@2ndquadrant.com> writes: > I'd guess that storing 8 per page would be optimal, so each stored xid would > track 4,000 transactions - probably around 1 sec worth of transactions when > the feature is used. This is something we can experiment with but I suspect that while 8 might be sufficient for many use cases there would be others where more would be better. The cost to having more lsns stored in the clog would be pretty small. On TPCC which has longer transactions on moderate hardware we only see order of 1,000 txn/min. So a setting like 128 which allows a granularity of 256 transactions would be about 15s which is not so much longer than the xmin horizon of the 90th percentile response time of 2*5s. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: