Re: Improving compressibility of WAL files
От | Hannu Krosing |
---|---|
Тема | Re: Improving compressibility of WAL files |
Дата | |
Msg-id | 1231458082.7525.8.camel@huvostro обсуждение исходный текст |
Ответ на | Re: Improving compressibility of WAL files (Hannu Krosing <hannu@krosing.net>) |
Список | pgsql-hackers |
On Fri, 2009-01-09 at 01:29 +0200, Hannu Krosing wrote: > On Thu, 2009-01-08 at 18:02 -0500, Aidan Van Dyk wrote: ... > > There's possible a few other ways to do it, such as zero the WAL on > > recycling (but not fsyncing it), and hopefully most of the zero's get > > trickled out by the OS before it comes down to a single 16MB fsync, but > > not many people seemed too enthused about the whole WAL compressablitly > > subject... > > > > But, the way I see things going on -hackers, I must admit, sync-rep (WAL > > streaming) looks like it's a long way off and possibly not even going to > > do what I want, so *I* would really like this wal zero'ing... > > > > If anybody has any specific things with the patch ehty think needs > > chaning, I'll try and accomidate, but I do note that I never > > submitted it for the Commitfest... > > won't it still be easier/less intrusive on inline core functionality and > more flexible to just record end-of-valid-wal somewhere and then let the > compressor discard the invalid part when compressing and recreate it > with zeros on decompression ? And some of the functionality already exists for in-process WAL files in form of pg_current_xlog_location() and pg_current_xlog_insert_location(), recording end-of-data in wal file just extends this to completed log files. -- ------------------------------------------ Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training
В списке pgsql-hackers по дате отправления: