Re: Cost of XLogInsert CRC calculations
| От | Simon Riggs |
|---|---|
| Тема | Re: Cost of XLogInsert CRC calculations |
| Дата | |
| Msg-id | 1117615809.3844.893.camel@localhost.localdomain обсуждение исходный текст |
| Ответ на | Re: Cost of XLogInsert CRC calculations (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Cost of XLogInsert CRC calculations
|
| Список | pgsql-hackers |
On Tue, 2005-05-31 at 22:36 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Hmmm. I seem to recall asking myself why xl_prev existed if it wasn't > > used, but passed that by. Damn. > > I couldn't believe it'd been overlooked this long, either. It's the > sort of thing that you assume got done the first time :-( Guess it shows how infrequently PostgreSQL crashes and recovers. > > PreAllocXLog was already a reason to have somebody prepare new xlog > > files ahead of them being used. Surely the right solution here is to > > have that agent prepare fresh/zeroed files prior to them being required. > > Uh, why? That doubles the amount of physical I/O required to maintain > the WAL, and AFAICS it doesn't really add any safety that we can't get > in a more intelligent fashion. OK, I agree that the xl_prev linkage is the more intelligent way to go. If I/O is a problem, then surely you will agree that PreAllocXLog is still required and should not be run by a backend? Thats going to show as a big response time spike for that user. Thats the last bastion - the other changes are gonna smooth response times right down, so can we do something with PreAllocXLog too? Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: