Re: ALTER TABLE ADD COLUMN fast default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE ADD COLUMN fast default
Date: 2021-04-05 16:21:36
Message-ID: 554951.1617639696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zhihong Yu <zyu(at)yugabyte(dot)com> writes:
>> if (found != ncheck)

> Since there is check on found being smaller than ncheck inside the loop,
> the if condition can be written as:
> if (found < ncheck)

Doesn't really seem like an improvement? Nor am I excited about renaming
these "found" variables, considering that those names can be traced back
more than twenty years.

> + if (found != ndef)
> + elog(WARNING, "%d attrdef record(s) missing for rel %s",
> + ndef - found, RelationGetRelationName(relation));

> Since only warning is logged, there seems to be some wasted space in
> attrdef. Would such space accumulate, resulting in some memory leak ?

No, it's just one palloc chunk either way. I do not think there is
any value in adding more code to reclaim the unused array slots a
bit sooner. (Because of aset.c's power-of-two allocation practices,
it's likely there would be zero actual space savings anyway.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-04-05 16:33:10 Re: Have I found an interval arithmetic bug?
Previous Message Tom Lane 2021-04-05 16:10:48 Re: ALTER TABLE ADD COLUMN fast default