| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER TABLE ADD COLUMN fast default |
| Date: | 2018-03-14 00:31:40 |
| Message-ID: | 20180314003140.mwbtwv5d5gprjhgb@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-03-14 09:06:54 +1030, Andrew Dunstan wrote:
> I do suspect that the "physical tlist" optimization sometimes turns
> out not to be one. It seems perverse to be able to improve a query's
> performance by dropping a column.
Yea, it's definitely not always a boon. Especially w/ the newer v10+
project code. I suspect we should largely get rid of it in v12, which
presumably will see a storage layer abstraction...
It'll be even more worthwhile to get rid of it if we manage to avoid
deforming columns that aren't needed but are lower than the currently
required columns. I still think we should build bitmasks of required
columns during planning.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2018-03-14 00:39:37 | Re: Fixes for missing schema qualifications |
| Previous Message | David Rowley | 2018-03-14 00:28:35 | Re: ALTER TABLE ADD COLUMN fast default |