Re: [HACKERS] increasing the default WAL segment size
От | David Steele |
---|---|
Тема | Re: [HACKERS] increasing the default WAL segment size |
Дата | |
Msg-id | 1dac9a13-8b47-14a5-8b7d-cad50b9984a5@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] increasing the default WAL segment size (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] increasing the default WAL segment size
Re: increasing the default WAL segment size |
Список | pgsql-hackers |
Hi Robert, On 3/22/17 3:45 PM, Robert Haas wrote: > On Wed, Mar 22, 2017 at 3:24 PM, David Steele <david@pgmasters.net> wrote: >>> One of the reasons to go with the LSN is that we would actually be >>> maintaining what happens when the WAL files are 16MB in size. >>> >>> David's initial expectation was this for 64MB WAL files: >>> >>> 000000010000000000000040 >>> 000000010000000000000080 >>> 0000000100000000000000CO >>> 000000010000000100000000 >> >> >> This is the 1GB sequence, actually, but idea would be the same for 64MB >> files. > > Wait, really? I thought you abandoned this approach because there's > then no principled way to handle WAL segments of less than the default > size. I did say that, but I thought I had hit on a compromise. But, as I originally pointed out the hex characters in the filename are not aligned correctly for > 8 bits (< 16MB segments) and using different alignments just made it less consistent. It would be OK if we were willing to drop the 1,2,4,8 segment sizes because then the alignment would make sense and not change the current 16MB sequence. Even then, there are some interesting side effects. For 1GB segments the "0000000100000001000000C0" segment would include LSNs 1/C0000000 through 1/FFFFFFFF. This is correct but is not an obvious filename to LSN mapping, at least for LSNs that appear later in the segment. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: