On 1/10/13 6:14 PM, Simon Riggs wrote:
On 10 January 2013 20:13, Tom Lane wrote:
Bruce Momjian 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 wa
On 10 January 2013 20:13, Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 irrelevant. The
On Wed, Jan 9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
> Simon Riggs 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
> > r
Simon Riggs 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 good idea.
I thi
On Wed, Jan 9, 2013 at 09:15:16PM +, Simon Riggs wrote:
> On 9 January 2013 21:02, Heikki Linnakangas 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 a
On 9 January 2013 20:54, Heikki Linnakangas 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 xl_tot_len, so that you re
On 9 January 2013 21:02, Heikki Linnakangas 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.
>
> However, th
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
the
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 redu
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 good
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 good idea.
The WAL record header starts with
12 matches
Mail list logo
