Re: ALTER TABLE ADD COLUMN fast default

Andrew Gierth writes: > This gitlab ticket refers to the same incident: > https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6047 > (which actually contains a new relevant fact that hadn't been mentioned > in the IRC discussion, which is that the problem affected multiple > tables, not just one

Re: ALTER TABLE ADD COLUMN fast default

> "Andrew" == Andrew Dunstan writes: Andrew> I'd be curious to know how this state came about. Me too, but available information is fairly sparse: PG 12.5, in a container, backing a (personal) instance of Gitlab; the only database admin operations should have been those done by Gitlab itsel

Re: ALTER TABLE ADD COLUMN fast default

Zhihong Yu 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

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On 4/4/21 6:50 PM, Tom Lane wrote: >> Meh. "pg_class.relchecks is inconsistent with the number of entries >> in pg_constraint" does not seem to me like a scary enough situation >> to justify a panic response. Maybe there's an argument for failing >> at the point where we

Re: ALTER TABLE ADD COLUMN fast default

On 4/4/21 6:50 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 4/4/21 12:05 PM, Tom Lane wrote: >>> I made CheckConstraintFetch likewise not install its array until >>> it's done. I notice that it is throwing elog(ERROR) not WARNING >>> for the equivalent cases of not finding the right numbe

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On 4/4/21 12:05 PM, Tom Lane wrote: >> I made CheckConstraintFetch likewise not install its array until >> it's done. I notice that it is throwing elog(ERROR) not WARNING >> for the equivalent cases of not finding the right number of >> entries. I wonder if we ought to b

Re: ALTER TABLE ADD COLUMN fast default

On Sun, Apr 04, 2021 at 02:18:34PM -0400, Andrew Dunstan wrote: > On 4/4/21 11:21 AM, Andrew Dunstan wrote: > > On 4/4/21 9:19 AM, Justin Pryzby wrote: > >> It reminded me of this thread, but nothing ever came of it. > >> https://www.postgresql.org/message-id/20200328223052.GK20103%40telsasoft.com

Re: ALTER TABLE ADD COLUMN fast default

On 4/4/21 11:21 AM, Andrew Dunstan wrote: > On 4/4/21 9:19 AM, Justin Pryzby wrote: >> It reminded me of this thread, but nothing ever came of it. >> https://www.postgresql.org/message-id/20200328223052.GK20103%40telsasoft.com >> >> >> https://www.postgresql.org/message-id/87pmzaq4gx.fsf%40news-s

Re: ALTER TABLE ADD COLUMN fast default

Hi, Thanks for the cleanup. if (found != ncheck) elog(ERROR, "%d constraint record(s) missing for rel %s", ncheck - found, RelationGetRelationName(relation)); Since there is check on found being smaller than ncheck inside the loop, the if condition can be written as:

Re: ALTER TABLE ADD COLUMN fast default

On 4/4/21 12:05 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 4/3/21 10:09 PM, Tom Lane wrote: >>> Looking around at the other touches of AttrDefault.adbin in the backend >>> (of which there are not that many), some of them are prepared for it to be >>> NULL and some are not. I don't immed

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On 4/3/21 10:09 PM, Tom Lane wrote: >> Looking around at the other touches of AttrDefault.adbin in the backend >> (of which there are not that many), some of them are prepared for it to be >> NULL and some are not. I don't immediately have a strong opinion whether >> that

Re: ALTER TABLE ADD COLUMN fast default

On 4/4/21 9:19 AM, Justin Pryzby wrote: > It reminded me of this thread, but nothing ever came of it. > https://www.postgresql.org/message-id/20200328223052.GK20103%40telsasoft.com > > > https://www.postgresql.org/message-id/87pmzaq4gx.fsf%40news-spur.riddles.org.uk > > I don't recall seeing thi

Re: ALTER TABLE ADD COLUMN fast default

On 4/3/21 10:09 PM, Tom Lane wrote: > Andrew Gierth writes: >> I just got through diagnosing a SEGV crash with someone on IRC, and the >> cause turned out to be exactly this - a table had (for some reason we >> could not determine within the available resources) lost its pg_attrdef >> record for

Re: ALTER TABLE ADD COLUMN fast default

It reminded me of this thread, but nothing ever came of it. https://www.postgresql.org/message-id/20200328223052.GK20103%40telsasoft.com https://www.postgresql.org/message-id/87pmzaq4gx.fsf%40news-spur.riddles.org.uk

Re: ALTER TABLE ADD COLUMN fast default

Andrew Gierth writes: > I just got through diagnosing a SEGV crash with someone on IRC, and the > cause turned out to be exactly this - a table had (for some reason we > could not determine within the available resources) lost its pg_attrdef > record for the one column it had with a default (which

Re: ALTER TABLE ADD COLUMN fast default

[warning, reviving a thread from 2018] > "Andrew" == Andrew Dunstan writes: > On Wed, Feb 21, 2018 at 7:48 PM, Andres Freund wrote: >> Hi, Andrew> Comments interspersed. >>> @@ -4059,10 +4142,6 @@ AttrDefaultFetch(Relation relation) >>> >>> systable_endscan(adscan); >>> heap_close

Re: ALTER TABLE ADD COLUMN fast default

On Fri, Mar 30, 2018 at 10:08 AM, Andrew Dunstan wrote: > On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote: [ missing values are loaded in the TupleDesc by RelationBuildTupleDesc ] >>> > I'm still strongly object to do doing this unconditionally for queries >>> > that never need any of this

Re: ALTER TABLE ADD COLUMN fast default

On 2018-03-29 16:40:29 -0700, Andres Freund wrote: > Hi, > > On 2018-03-30 10:08:54 +1030, Andrew Dunstan wrote: > > On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote: > > > this'll trigger one slot_getsomeattrs(slot, 2) call from within qual > > > evaluation, and then a slot_getsomeattrs(slot,

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-03-30 10:08:54 +1030, Andrew Dunstan wrote: > On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote: > > this'll trigger one slot_getsomeattrs(slot, 2) call from within qual > > evaluation, and then a slot_getsomeattrs(slot, 4) from within the > > projection code. If you then imagine

Re: ALTER TABLE ADD COLUMN fast default

On Fri, Mar 30, 2018 at 5:00 AM, Andres Freund wrote: > Hi, > > On 2018-03-29 10:16:23 +1030, Andrew Dunstan wrote: >> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: >> > Hi, >> > >> > On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote: >> >> Thanks for this, all looks good. Here is the co

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-03-30 00:28:43 +0200, Tomas Vondra wrote: > > Why is that unlikely? In the field it's definitely not uncommon to > > define default values for just about every column. And in a lot of cases > > that'll mean we'll end up with pg_attribute containing default values > > for most columns

Re: ALTER TABLE ADD COLUMN fast default

On 03/29/2018 11:31 PM, Andres Freund wrote: > Hi, > > On 2018-03-29 17:27:47 -0400, Tom Lane wrote: >> Andres Freund writes: >>> There's plenty databases with pg_attribute being many gigabytes large, >>> and this is going to make that even worse. >> >> Only if you imagine that a sizable fracti

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-03-29 17:27:47 -0400, Tom Lane wrote: > Andres Freund writes: > > There's plenty databases with pg_attribute being many gigabytes large, > > and this is going to make that even worse. > > Only if you imagine that a sizable fraction of the columns have fast > default values, which see

Re: ALTER TABLE ADD COLUMN fast default

Andres Freund writes: > There's plenty databases with pg_attribute being many gigabytes large, > and this is going to make that even worse. Only if you imagine that a sizable fraction of the columns have fast default values, which seems somewhat unlikely. regards, tom lan

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-03-29 10:16:23 +1030, Andrew Dunstan wrote: > On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: > > Hi, > > > > On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote: > >> Thanks for this, all looks good. Here is the consolidate patch > >> rebased. If there are no further comments I

Re: ALTER TABLE ADD COLUMN fast default

On Mon, Mar 26, 2018 at 9:32 AM, Andrew Dunstan wrote: > > > Thanks for this, all looks good. Here is the consolidate patch > rebased. If there are no further comments I propose to commit this in > a few days time. I have some comments with the committed patch. @@ -663,7 +671,23 @@ ExecFetchSlo

Re: ALTER TABLE ADD COLUMN fast default

On Thu, Mar 29, 2018 at 10:19 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: >>> + /* >>> +* Missing value for added columns. This is a one element array >>> which lets >>> +* us store a value of the attribute type her

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: >> + /* >> +* Missing value for added columns. This is a one element array >> which lets >> +* us store a value of the attribute type here. >> +*/ >> + anyarrayattmissingval

Re: ALTER TABLE ADD COLUMN fast default

On Wed, Mar 28, 2018 at 5:30 PM, Andres Freund wrote: > Hi, > > On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote: >> Thanks for this, all looks good. Here is the consolidate patch >> rebased. If there are no further comments I propose to commit this in >> a few days time. > > Here's a bit of pos

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-03-26 09:02:10 +1030, Andrew Dunstan wrote: > Thanks for this, all looks good. Here is the consolidate patch > rebased. If there are no further comments I propose to commit this in > a few days time. Here's a bit of post commit review: @@ -1310,13 +1679,11 @@ slot_getsomeattrs(TupleT

Re: ALTER TABLE ADD COLUMN fast default

On 25 March 2018 at 23:43, David Rowley wrote: > With the attached applied, I'm happy to mark the patch as ready for > committer, however, Petr is also signed up to review, so will defer to > him to see if he has any comments before altering the commitfest app's > state. Petr won't have time to l

Re: ALTER TABLE ADD COLUMN fast default

On Sun, Mar 25, 2018 at 9:13 PM, David Rowley wrote: > On 25 March 2018 at 20:09, David Rowley wrote: >> On 15 March 2018 at 21:33, Andrew Dunstan >> wrote: >>> rebased and mostly indented patch version attached. >> >> Thanks. I've attached a version of this which applies, builds and >> passes t

Re: ALTER TABLE ADD COLUMN fast default

On 25 March 2018 at 20:09, David Rowley wrote: > On 15 March 2018 at 21:33, Andrew Dunstan > wrote: >> rebased and mostly indented patch version attached. > > Thanks. I've attached a version of this which applies, builds and > passes the regression tests on current master. > > Some conflicts were

Re: Re: ALTER TABLE ADD COLUMN fast default

On 3/15/18 4:33 AM, Andrew Dunstan wrote: > > rebased and mostly indented patch version attached. It's actually > moderately difficult to produce a nicely indented patch that is > against non-pgindented code. We should look at that a bit. Another > item for my TODO list. It looks like this should

Re: ALTER TABLE ADD COLUMN fast default

> On Mar 14, 2018, at 10:58 AM, David Rowley > wrote: > > On 14 March 2018 at 11:36, Andrew Dunstan > wrote: >> Here are the benchmark results from the v15 patch. Fairly similar to >> previous results. I'm going to run some profiling again to see if I >> can identify any glaring hotspots. I

Re: ALTER TABLE ADD COLUMN fast default

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

Re: ALTER TABLE ADD COLUMN fast default

On 14 March 2018 at 11:36, Andrew Dunstan wrote: > Here are the benchmark results from the v15 patch. Fairly similar to > previous results. I'm going to run some profiling again to see if I > can identify any glaring hotspots. I do suspect that the "physical > tlist" optimization sometimes turns o

Re: ALTER TABLE ADD COLUMN fast default

On Tue, Mar 13, 2018 at 10:58 PM, Andrew Dunstan wrote: > On Tue, Mar 13, 2018 at 2:40 PM, Andrew Dunstan > wrote: > >>> >>> Going by the commitfest app, the patch still does appear to be waiting >>> on Author. Never-the-less, I've made another pass over it and found a >>> few mistakes and a coup

Re: ALTER TABLE ADD COLUMN fast default

On Mon, Mar 12, 2018 at 1:29 AM, David Rowley wrote: > On 9 March 2018 at 02:11, David Rowley wrote: >> On 8 March 2018 at 18:40, Andrew Dunstan >> wrote: >>> select * from t; >>> fastdef tps = 107.145811 >>> master tps = 150.207957 >>> >>> "select * from t" used to be about a wash, but wit

Re: ALTER TABLE ADD COLUMN fast default

On 9 March 2018 at 02:11, David Rowley wrote: > On 8 March 2018 at 18:40, Andrew Dunstan > wrote: >> select * from t; >> fastdef tps = 107.145811 >> master tps = 150.207957 >> >> "select * from t" used to be about a wash, but with this patch it's >> got worse. The last two queries were worse

Re: ALTER TABLE ADD COLUMN fast default

On 8 March 2018 at 18:40, Andrew Dunstan wrote: > select * from t; > fastdef tps = 107.145811 > master tps = 150.207957 > > "select * from t" used to be about a wash, but with this patch it's > got worse. The last two queries were worse and are now better, so > that's a win. How does it compa

Re: ALTER TABLE ADD COLUMN fast default

On Tue, Mar 6, 2018 at 8:15 PM, David Rowley wrote: > On 6 March 2018 at 22:40, David Rowley wrote: >> Okay, it looks like the patch should disable physical tlists when >> there's a missing column the same way as we do for dropped columns. >> Patch attached. > > Please disregard the previous patc

Re: ALTER TABLE ADD COLUMN fast default

On 6 March 2018 at 22:40, David Rowley wrote: > Okay, it looks like the patch should disable physical tlists when > there's a missing column the same way as we do for dropped columns. > Patch attached. Please disregard the previous patch in favour of the attached. -- David Rowley

Re: ALTER TABLE ADD COLUMN fast default

On 1 March 2018 at 11:49, Andrew Dunstan wrote: > On Wed, Feb 28, 2018 at 5:39 AM, Andres Freund wrote: >> On 2018-02-27 14:29:44 +1030, Andrew Dunstan wrote: >>> Profiling through timer interrupt >>> samples %image name symbol name >>> 2258428.5982 postgres

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-27 14:29:44 +1030, Andrew Dunstan wrote: > This was debated quite some time ago. See for example > > The consensus then seemed to be to store them in pg_attribute. If not, > I think we'd need a new catalog - pg

Re: ALTER TABLE ADD COLUMN fast default

On Wed, Feb 21, 2018 at 7:48 PM, Andres Freund wrote: > Hi, > [ Long and useful review] > This doesn't seem ready yet. > Thanks. I'm working through the issues you raised. Will reply in a few days. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Devel

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-20 17:03:07 +1030, Andrew Dunstan wrote: > + > + attmissingval > + bytea > + > + > + This column has a binary representation of the value used when the > + column is entirely missing from the row, as happens when the column is > + added a

Re: ALTER TABLE ADD COLUMN fast default

David Rowley writes: > It seems the difference between these two cases is down to > slot_getsomeattrs being asked to deform up to attnum 1000 for the > create-alter.sql case, and only up to attnum 10 for the create.sql > case. Both plans are using physical tlists per EXPLAIN VERBOSE. I've > not ma

Re: ALTER TABLE ADD COLUMN fast default

On 21 February 2018 at 00:38, David Rowley wrote: > Using: select sum(c10) from t; > ... > v11 + create.sql: tps = 3330.131437 > v11 + create-alter.sql: tps = 1398.635251 It seems the difference between these two cases is down to slot_getsomeattrs being asked to deform up to attnum 1000 for the c

Re: ALTER TABLE ADD COLUMN fast default

On 02/20/2018 09:36 PM, Andres Freund wrote: > Hi, > > On 2018-02-20 21:28:40 +0100, Tomas Vondra wrote: >> I don't quite understand why would this case need the TPC-H tests, or >> why would TPC-H give us more than the very focused tests we've already >> done. > > Because a more complex query s

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-20 21:28:40 +0100, Tomas Vondra wrote: > I don't quite understand why would this case need the TPC-H tests, or > why would TPC-H give us more than the very focused tests we've already > done. Because a more complex query shows the cost of changing cache access costs better than a t

Re: ALTER TABLE ADD COLUMN fast default

On 02/20/2018 09:14 PM, Tom Lane wrote: > Andres Freund writes: >> On 2018-02-20 20:57:36 +0100, Tomas Vondra wrote: >>> The question is how should the schema for TPC-H look like. Because if >>> you just do the usual test without any ALTER TABLE ADD COLUMN, then you >>> really won't get any diffe

Re: ALTER TABLE ADD COLUMN fast default

Andres Freund writes: > On 2018-02-20 20:57:36 +0100, Tomas Vondra wrote: >> The question is how should the schema for TPC-H look like. Because if >> you just do the usual test without any ALTER TABLE ADD COLUMN, then you >> really won't get any difference at all. The fast default stuff will be >>

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-20 20:57:36 +0100, Tomas Vondra wrote: > The question is how should the schema for TPC-H look like. Because if > you just do the usual test without any ALTER TABLE ADD COLUMN, then you > really won't get any difference at all. The fast default stuff will be > completely "inactive".

Re: ALTER TABLE ADD COLUMN fast default

On 02/20/2018 06:43 PM, Andres Freund wrote: > > > On February 20, 2018 5:03:58 AM PST, Petr Jelinek > wrote: >> 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 >> co

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-20 13:50:54 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2018-02-20 13:07:30 -0500, Tom Lane wrote: > >> I can easily think of problems that will ensue if we try to support that > >> case, because right now the toast mechanisms assume that OOL toasted > >> values can only

Re: ALTER TABLE ADD COLUMN fast default

Andres Freund writes: > On 2018-02-20 13:07:30 -0500, Tom Lane wrote: >> I can easily think of problems that will ensue if we try to support that >> case, because right now the toast mechanisms assume that OOL toasted >> values can only be referenced from the associated table. > What problem are

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-02-20 13:07:30 -0500, Tom Lane wrote: > ... btw, I've not read this patch in any detail, but the recent thread > about toast tables for system catalogs prompts me to wonder what happens > if a "fast default" value is large enough to require out-of-line toasting. Hm, interesting. > I

Re: ALTER TABLE ADD COLUMN fast default

... btw, I've not read this patch in any detail, but the recent thread about toast tables for system catalogs prompts me to wonder what happens if a "fast default" value is large enough to require out-of-line toasting. I can easily think of problems that will ensue if we try to support that case,

Re: ALTER TABLE ADD COLUMN fast default

On February 20, 2018 5:03:58 AM PST, Petr Jelinek wrote: >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. >

Re: ALTER TABLE ADD COLUMN fast default

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 thi

Re: ALTER TABLE ADD COLUMN fast default

On 20 February 2018 at 23:10, David Rowley wrote: > Nevertheless, it would be interesting to see how much a bsearch in > getmissingattr would help Tomas' case. Though, perhaps you're happy > enough with the performance already. I thought I'd give this a quick test using the attached (incomplete)

Re: ALTER TABLE ADD COLUMN fast default

Thanks for making those updates . On 20 February 2018 at 19:33, Andrew Dunstan wrote: > On Mon, Feb 19, 2018 at 1:18 PM, David Rowley > wrote: >> Since the attnum order in the missing values appears to be well >> defined in ascending order, you can also simplify the comparison logic >> in equalTu

Re: ALTER TABLE ADD COLUMN fast default

On Tue, Feb 20, 2018 at 5:03 PM, Andrew Dunstan wrote: > http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2 Wow, my c&p was working overtime. Good thing this won't do anyone any good. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadr

Re: ALTER TABLE ADD COLUMN fast default

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 de

Re: ALTER TABLE ADD COLUMN fast default

http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2 On Mon, Feb 19, 2018 at 1:18 PM, David Rowley wrote: > On 19 February 2018 at 13:48, Andrew Dunstan > wrote: >> On Sun, Feb 18, 2018 at 2:52 PM, David Rowley >> wrote: >>> I'll try to spend some time revi

Re: ALTER TABLE ADD COLUMN fast default

On 19 February 2018 at 13:48, Andrew Dunstan wrote: > On Sun, Feb 18, 2018 at 2:52 PM, David Rowley > wrote: >> I'll try to spend some time reviewing the code in detail soon. >> > > Thanks. I'll fix the typos in the next version of the patch, hopefully > after your review. Here's a more complete

Re: ALTER TABLE ADD COLUMN fast default

On Sun, Feb 18, 2018 at 2:52 PM, David Rowley wrote: > On 17 February 2018 at 10:46, Andrew Dunstan > wrote: >> The attached version largely fixes with the performance degradation >> that Tomas Vondra reported, replacing an O(N^2) piece of code in >> slot_getmissingattrs() by one that is O(N). >

Re: ALTER TABLE ADD COLUMN fast default

On 17 February 2018 at 10:46, Andrew Dunstan wrote: > The attached version largely fixes with the performance degradation > that Tomas Vondra reported, replacing an O(N^2) piece of code in > slot_getmissingattrs() by one that is O(N). I've looked over this patch and had a play around with it. Ju

Re: ALTER TABLE ADD COLUMN fast default

On 02/16/2018 10:46 PM, Andrew Dunstan wrote: > On Tue, Feb 13, 2018 at 6:28 PM, Andrew Dunstan > wrote: >> On Fri, Feb 9, 2018 at 3:54 PM, Andrew Dunstan >> wrote: >>> On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan >>> wrote: On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro wrote:

Re: ALTER TABLE ADD COLUMN fast default

On Tue, Feb 13, 2018 at 6:28 PM, Andrew Dunstan wrote: > On Fri, Feb 9, 2018 at 3:54 PM, Andrew Dunstan > wrote: >> On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan >> wrote: >>> On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro >>> wrote: On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan wro

Re: ALTER TABLE ADD COLUMN fast default

On Fri, Feb 9, 2018 at 3:54 PM, Andrew Dunstan wrote: > On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan > wrote: >> On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro >> wrote: >>> On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan >>> wrote: Yeah, thanks. revised patch attached >>> >>> FYI the iden

Re: ALTER TABLE ADD COLUMN fast default

On Sun, Feb 11, 2018 at 2:50 PM, Petr Jelinek wrote: >> >> >> Here's a version that fixes the above issue and also the issue with >> VACUUM that Tomas Vondra reported. I'm still working on the issue with >> aggregates that Tomas also reported. >> > > I see the patch does not update the ALTER TABL

Re: ALTER TABLE ADD COLUMN fast default

On 09/02/18 06:24, Andrew Dunstan wrote: > On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan > wrote: >> On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro >> wrote: >>> On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan >>> wrote: Yeah, thanks. revised patch attached >>> >>> FYI the identity regressio

Re: ALTER TABLE ADD COLUMN fast default

On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan wrote: > On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro > wrote: >> On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan >> wrote: >>> Yeah, thanks. revised patch attached >> >> FYI the identity regression test started failing recently with this >> patch a

Re: ALTER TABLE ADD COLUMN fast default

On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro wrote: > On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan > wrote: >> Yeah, thanks. revised patch attached > > FYI the identity regression test started failing recently with this > patch applied (maybe due to commit > 533c5d8bddf0feb1785b3da17c0d17feeaa

Re: ALTER TABLE ADD COLUMN fast default

On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan wrote: > Yeah, thanks. revised patch attached FYI the identity regression test started failing recently with this patch applied (maybe due to commit 533c5d8bddf0feb1785b3da17c0d17feeaac76d8?) *** /home/travis/build/postgresql-cfbot/postgresql/src/

Re: ALTER TABLE ADD COLUMN fast default

Hi, On 2018-01-26 10:53:12 +1030, Andrew Dunstan wrote: > Yeah, thanks. revised patch attached Given that this patch touches code that's a huge bottleneck in a lot of cases, I think this needs benchmarks that heavily exercises tuple deforming. Greetings, Andres Freund

Re: ALTER TABLE ADD COLUMN fast default

On Thu, Jan 25, 2018 at 6:10 PM, Thomas Munro wrote: > On Wed, Jan 17, 2018 at 2:21 AM, Andrew Dunstan > wrote: >> Yeah, got caught by the bki/pg_attribute changes on Friday. here's an >> updated version. Thanks for looking. > > A boring semi-automated update: this no long compiles, because > 85

Re: ALTER TABLE ADD COLUMN fast default

On Wed, Jan 17, 2018 at 2:21 AM, Andrew Dunstan wrote: > Yeah, got caught by the bki/pg_attribute changes on Friday. here's an > updated version. Thanks for looking. A boring semi-automated update: this no long compiles, because 8561e4840c8 added a new call to heap_attisnull(). Pretty sure it j

Re: ALTER TABLE ADD COLUMN fast default

On 01/16/2018 12:13 AM, David Rowley wrote: > On 2 January 2018 at 05:01, Andrew Dunstan > wrote: >> New version of the patch that fills in the remaining piece in >> equalTupleDescs. > This no longer applies to current master. Can send an updated patch? > Yeah, got caught by the bki/pg_attribu

Re: ALTER TABLE ADD COLUMN fast default

On 2 January 2018 at 05:01, Andrew Dunstan wrote: > New version of the patch that fills in the remaining piece in > equalTupleDescs. This no longer applies to current master. Can send an updated patch? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: ALTER TABLE ADD COLUMN fast default

On 12/31/2017 06:48 PM, Andrew Dunstan wrote: > > Here is a new version of the patch. It separates the missing values > constructs and logic from the default values constructs and logic. The > missing values now sit alongside the default values in tupleConstr. In > some places the separation make

Re: ALTER TABLE ADD COLUMN fast default

On 12/12/2017 02:13 PM, Andrew Dunstan wrote: > > On 12/06/2017 11:26 AM, Andrew Dunstan wrote: >>> In general, you need to be thinking about this in terms of making sure >>> that it's impossible to accidentally not update code that needs to be >>> updated. Another example is that I noticed that

Re: ALTER TABLE ADD COLUMN fast default

On 12/06/2017 11:26 AM, Andrew Dunstan wrote: >> In general, you need to be thinking about this in terms of making sure >> that it's impossible to accidentally not update code that needs to be >> updated. Another example is that I noticed that some places the patch >> has s/CreateTupleDescCopy/C

Re: ALTER TABLE ADD COLUMN fast default

On 12/06/2017 11:05 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 12/06/2017 10:16 AM, Tom Lane wrote: >>> 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-deconstructi

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On 12/06/2017 10:16 AM, Tom Lane wrote: >> 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 som

Re: ALTER TABLE ADD COLUMN fast default

On 12/06/2017 10:16 AM, Tom Lane wrote: > Andrew Dunstan 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 s

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan 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