On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
