| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Serge Rielau <serge(at)rielau(dot)com>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fast AT ADD COLUMN with DEFAULTs |
| Date: | 2016-10-10 04:02:12 |
| Message-ID: | CADkLM=cq9k95=oN_pmeeU2f3Ue2eHv4_qiotEkL9aR0ke27GrQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> There's actually another use case here that's potentially extremely
> valuable for warehousing and other "big data": compact representation of a
> default value.
>
>
I too would benefit from tables having either a default value in the event
of a NOT-NULL column being flagged null, or a flat-out constant.
This would be a big win in partitioned tables where the partition can only
hold one value of the partitioning column.
I guess a constant would be a pg_type where the sole value is encoded, and
the column itself is stored like an empty string.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2016-10-10 04:04:09 | Re: proposal: psql \setfileref |
| Previous Message | Jim Nasby | 2016-10-10 03:26:07 | Re: proposal: psql \setfileref |