Re: ALTER TABLE ADD COLUMN fast default - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ALTER TABLE ADD COLUMN fast default
Date
Msg-id 379d80b8-c02b-111c-fb75-fb80204518f4@2ndQuadrant.com
Whole thread Raw
In response to Re: ALTER TABLE ADD COLUMN fast default  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE ADD COLUMN fast default  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 12/06/2017 10:16 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> Attached is a patch for $subject. It's based on Serge Reilau's patch of
>> about a year ago, taking into account comments made at the time. with
>> bitrot removed and other enhancements such as documentation.
>> Essentially it stores a value in pg_attribute that is used when the
>> stored tuple is missing the attribute. This works unless the default
>> expression is volatile, in which case a table rewrite is forced as
>> happens now.
> I'm quite disturbed both by the sheer invasiveness of this patch
> (eg, changing the API of heap_attisnull()) and by the amount of logic
> it adds to fundamental tuple-deconstruction code paths.  I think
> we'll need to ask some hard questions about whether the feature gained
> is worth the distributed performance loss that will ensue.
>
>             


Thanks for prompt comments.

I'm sure we can reduce the footprint some.

w.r.t. heap_attisnull, only a handful of call sites actually need the
new functionality, 8 or possibly 10 (I need to check more on those in
relcache.c). So we could instead of changing the function provide a new
one to be used at those sites. I'll work on that. and submit a new patch
fairly shortly.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Dang Minh Huong
Date:
Subject: Re: User defined data types in Logical Replication
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default