On 04/17/2015 08:36 PM, Simon Riggs wrote:
> On 17 April 2015 at 18:12, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
>> On 04/17/2015 12:04 PM, Simon Riggs wrote:
>>
>>> On 17 April 2015 at 09:54, Andres Freund <andres@anarazel.de> wrote:
>>>
>>> Hrmpf. Says the person that used a lot of padding, without much
>>>> discussion, for the WAL level infrastructure making pg_rewind more
>>>> maintainable.
>>>
>>> Sounds bad. What padding are we talking about?
>>
>> In the new WAL format, the data chunks are stored unaligned, without
>> padding, to save space. The new format is quite different to the old one,
>> so it's not straightforward to compare how much that saved.
>
> The key point here is the whole WAL format was changed to accommodate a
> minor requirement for one utility. Please notice that nobody tried to stop
> you doing that.
>
> The changes Andres is requesting have a very significant effect on a major
> new facility. Perhaps there is concern that it is an external utility?
>
> If we can trust Heikki to include code into core that was written
> externally then I think we can do the same for Andres.
I'm not concerned of the fact it is an external utility. Well, it
concerns me a little bit, because that means that it'll get little
testing with PostgreSQL. But that has nothing to do with the WAL size
question.
> I think its time to stop the padding discussion and commit something
> useful. We need this.
To be honest, I'm not entirely sure what we're arguing over. I said that
IMO the difference in WAL size is so small that we should just use
4-byte OIDs for the replication identifiers, instead of trying to make
do with 2 bytes. Not because I find it too likely that you'll run out of
IDs (although it could happen), but more to make replication IDs more
like all other system objects we have. Andreas did some pgbench
benchmarking to show that the difference in WAL size is about 10%. The
WAL records generated by pgbench happen to have just the right sizes so
that the 2-3 extra bytes bump them over to the next alignment boundary.
That's why there is such a big difference - on average it'll be less. I
think that's acceptable, Andreas seems to think otherwise. But if the
WAL size really is so precious, we could remove the two padding bytes
from XLogRecord, instead of dedicating them for the replication ids.
That would be an even better use for them.
- Heikki