On 06/24/2013 02:21 PM, Tom Lane wrote: >> Right, but I'm worried about the "surprise!" factor. That is, if we >> make the first default "free" by using a magic value, then a SET DEFAULT >> on that column is going to have some very surprising results as suddenly >> the whole table needs to get written out for the old default. > > No, that's why we'd store the magic default separately. That will be > permanent and unaffected by later SET DEFAULT operations. (This > requires that every subsequently created tuple store the column > explicitly so that the magic default doesn't affect it; which is exactly > why there's a conflict with the currently-proposed patch.)
Yah. So how likely is this to get done sometime in the next 2 releases? It's only a conflict if someone is going to write the code ... > Agreed; there are a lot of things we'd have to address if we really > wanted to claim this is a domain we work well in. (I suspect Salesforce > will be chipping away at some of those issues, but as I said, > heap_form_tuple is not in their critical path.) Well, doing the trailing column truncation as part of a general plan to make having 600 columns less painful would make more sense than doing it on its own. For my personal use case(s), I don't really care about the null bitmap that much; that amount of space simply isn't that significant compared to the other performance issues involved. I started evaluating this patch just because I'm one of the few people with a realistic test case. Anyway, let's decide if acceptance of this patch hinges on performance or not. I'll take me a whole evening to set up a good performance test, so I don't want to do it if it's going to be a moot point. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
