Re: logical changeset generation v6.2

On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > In my opinion, (4) is too ugly to consider. I think that if we start
>> > playing games like this, we're opening up the doors to lots of subtle
>> > bugs and future architectural pain that will be with us for many, many
>> > years to come. I believe we will bitterly regret any foray into this
>> > area.
>>
>> Hm. After looking at the required code - which you obviously cannot have
>> yet - it's not actually too bad. Will post a patch implementing it later.
>>
>> I don't really buy the architectural argument since originally cmin/cmax
>> *were* both stored. It's not something we're just inventing now. We just
>> optimized that away but now have discovered that's not always a good
>> idea and thus don't always use the optimization.
>>
>> The actual decoding code shrinks by about 200 lines using this logic
>> which is a hint that it's not a bad idea.
>
> So, here's a preliminary patch to see how this would look. It'd be great
> of you comment if you still think it's a completel no-go.
>
> If it were for real, it'd need to be split and some minor things would
> need to get adjusted, but I think it's easier to review it seing both
> sides at once.

I think it's a complete no-go. Consider, e.g., the comment for
MaxTupleAttributeNumber, which you've blithely falsified. Even if you
update the comment and the value, I'm not inspired by the idea of
subtracting 32 from that number; even if it weren't already too small,
it would break pg_upgrade for any users who are on the edge. Things
aren't looking too good for anything that uses HeapTupleFields,
either; consider rewrite_heap_tuple().

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company