| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(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-02-20 13:03:58 |
| Message-ID: | bfe66438-7c3c-baf1-acbe-e0d16c6b17cb@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20/02/18 07:42, Andres Freund wrote:
> Hi,
>
> On 2018-02-17 00:23:40 +0100, Tomas Vondra wrote:
>> Anyway, I consider the performance to be OK. But perhaps Andres could
>> comment on this too, as he requested the benchmarks.
>
> My performance concerns were less about CREATE TABLE related things than
> about analytics workloads or such, where deforming is the primary
> bottleneck. I think it should be ok, but doing a before/after tpc-h of
> scale 5-10 or so wouldn't be a bad thing to verify.
>
The test Tomas is doing is analytical query, it's running sum on the new
fast default column.
He uses create and create-alter names as comparison between when the
table was created with the columns and when the columns were added using
fast default.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2018-02-20 13:19:18 | Re: Contention preventing locking |
| Previous Message | Amit Kapila | 2018-02-20 12:39:41 | Re: heap_lock_updated_tuple_rec can leak a buffer refcount |