Re: CommitDelay performance improvement
От | Philip Warner |
---|---|
Тема | Re: CommitDelay performance improvement |
Дата | |
Msg-id | 3.0.5.32.20010224145412.03240ba0@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: CommitDelay performance improvement (ncm@zembu.com (Nathan Myers)) |
Ответы |
Re: CommitDelay performance improvement
|
Список | pgsql-hackers |
At 14:57 23/02/01 -0800, Nathan Myers wrote: > >When thinking about tuning N, I like to consider what are the interesting >possible values for N: > It may have been much earler in the debate, but has anyone checked to see what the maximum possible gains might be - or is it self-evident to people who know the code? Would it be worth considering creating a test case with no flush in RecordTransactionCommit, and rely on checkpointing to flush? I realize this is never an option in production, but is it possible to modify the code in this way? I *should* give an upper limit on the gains that can be made by flushing at the best possible time. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: