On Mon, Jun 24, 2013 at 4:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > The point of what I was suggesting isn't to conserve storage, but to > reduce downtime during a schema change. Remember that a rewriting ALTER > TABLE locks everyone out of that table for a long time.
Sure, I understand. As Josh says, though, it'd still be potentially quite surprising. >> So, Tom, how's that pluggable storage format coming? :-) > > Well, actually, it's looking to me like heap_form_tuple will be > underneath the API cut, because alternate storage managers will probably > have other tuple storage formats --- column stores being the poster > child here, but in any case the tuple header format is very unlikely > to be universal. I've had the same thought. Unfortunately, there are a lot of things - like the TupleTableSlot abstraction - that are fairly deeply in bed with the format used by our current heap AM; so we might be imposing a performance overhead for anyone who uses some other representation. Unless you have some idea how to avoid that? > Which means that whether this patch gets applied to mainline is going > to be moot for Salesforce's purposes; they will certainly want the > equivalent logic in their storage code, because they've got tables with > many hundreds of mostly-null columns, but whether heap_form_tuple acts > this way or not won't affect them. OK. > So unless we consider that many-hundreds-of-columns is a design center > for general purpose use of Postgres, we should be evaluating this patch > strictly on its usefulness for more typical table widths. And my take > on that is that (1) lots of columns isn't our design center (for the > reasons you mentioned among others), and (2) the case for the patch > looks pretty weak otherwise. I guess I have yet to be convinced that it really hurts anything. Your example seems fairly hypothetical and could easily be something no one ever implements. I don't feel terribly strongly that we need to take this patch, and I don't really care that much whether we do or not; I'm just not really convinced there's any actual evidence that we shouldn't. The standard isn't that it's got to make something really important better; it's just got to make something better without making anything more important worse. -- 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
