On 06/24/2013 01:50 PM, Tom Lane 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.
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.
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. In many
use cases, this would still be a net win, since 80% of the time users
don't change defaults after column creation. But we'd have to make it
much less surprising somehow. Also for the reason Tom pointed out, the
optimization would only work on with NOT NULL columns ... leading to
another potential unexpected surprise when the column is marked NULLable.
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.
Well, actually, hundreds of columns is reasonably common for a certainfor 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.
user set (ERP, CRM, etc.). If we could handle that use case very
efficiently, then it would win us some users, since other RDMBSes don't.
However, there are multiple issues with having hundreds of columns, of
which storage optimization is only one ... and probably the smallest one
at that.
