Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
От | Robert Haas |
---|---|
Тема | Re: AdvanceXLInsertBuffer vs. WAL segment compressibility |
Дата | |
Msg-id | CA+TgmobKFW5eVx4gd9TyiXv9iL_5DcC0-6UuJLXvwG1Ft1Pn-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: AdvanceXLInsertBuffer vs. WAL segment compressibility (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
|
Список | pgsql-hackers |
On Tue, Aug 2, 2016 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, Jul 26, 2016 at 05:42:43PM -0400, Chapman Flack wrote: >> Even so, I'd be curious whether it would break anything to have >> xlp_pageaddr simply set to InvalidXLogRecPtr in the dummy zero >> pages written to fill out a segment. At least until it's felt >> that archive_timeout has been so decidedly obsoleted by streaming >> replication that it is removed, and the log-tail zeroing code >> with it. >> >> That at least would eliminate the risk of anyone else repeating >> my astonishment. :) I had read that 9.4 added built-in log-zeroing >> code, and my first reaction was "cool! that may make the compression >> technique we're using unnecessary, but certainly can't make it worse" >> only to discover that it did, by ~ 300x, becoming now 3x *worse* than >> plain gzip, which itself is ~ 100x worse than what we had. > > My guess is that the bytes are there to detect problems where a 512-byte > disk sector is zeroed by a disk failure. I don't see use changing that > for the use-case you have described. Is there actually any code that makes such a check? I'm inclined to doubt that was the motivation, though admittedly we're both speculating about the contents of Heikki's brain, a tricky proposition on a good day. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: