On 04/17/2015 11:36 PM, Simon Riggs wrote:
> On 17 April 2015 at 19:18, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> To be honest, I'm not entirely sure what we're arguing over.
>
> When arguing over something you consider small, it is customary to allow
> the author precedence. We can't do things our own way all the time.
Sure, I'm not going to throw a tantrum if Andres commits this as it is.
>> 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.
>
> The argument to move to 4 bytes is a poor one. If it was reasonable in
> terms of code or cosmetic value then all values used in the backend would
> be 4 bytes. We wouldn't have any 2 byte values anywhere. But we don't do
> that.
That's a straw man argument. I'm not saying we should never use 2 byte
values anywhere. OID is usually used as the primary key in system
tables. There are exceptions, but that is nevertheless the norm. I'm
saying that saving in WAL size is not worth making an exception here,
and we should go with the simplest option of using OIDs.
- Heikki