On 1/10/13 6:14 PM, Simon Riggs wrote:
On 10 January 2013 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
Let's wait till we see where the logical rep stuff ends up before we
worry about saving 4 bytes
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it by 8
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
Let's wait till we see where the logical rep stuff ends up before we
worry about saving 4 bytes per WAL record.
Well, we have wal_level to control the amount of WAL traffic.
That's entirely
On 10 January 2013 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
Let's wait till we see where the logical rep stuff ends up before we
worry about saving 4 bytes per WAL record.
Well, we have
On 09.01.2013 22:36, Simon Riggs wrote:
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it by 8 bytes per
record. So looking for ways to do that seems like a
On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote:
On 09.01.2013 22:36, Simon Riggs wrote:
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it
On 09.01.2013 22:59, Bruce Momjian wrote:
On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote:
On 09.01.2013 22:36, Simon Riggs wrote:
The WAL record header starts with xl_tot_len, a 4 byte field. There is
also another field, xl_len. The difference is that xl_tot_len includes
On 9 January 2013 21:02, Heikki Linnakangas hlinnakan...@vmware.com wrote:
OK, crazy idea, but can we just record xl_len as a difference against
xl_tot_len, and shorten the xl_len field?
Hmm, so it would essentially be the length of all the backup blocks. perhaps
rename it to xl_bkpblk_len.
On 9 January 2013 20:54, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Here's a better idea:
Let's keep xl_tot_len as it is, but move xl_len at the very end of the WAL
record, after all the backup blocks. If there are no backup blocks, xl_len
is omitted. Seems more robust to keep
On Wed, Jan 9, 2013 at 09:15:16PM +, Simon Riggs wrote:
On 9 January 2013 21:02, Heikki Linnakangas hlinnakan...@vmware.com wrote:
OK, crazy idea, but can we just record xl_len as a difference against
xl_tot_len, and shorten the xl_len field?
Hmm, so it would essentially be the
Simon Riggs si...@2ndquadrant.com writes:
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it by 8 bytes per
record. So looking for ways to do that seems like a
11 matches
Mail list logo
