Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011: > Peter Eisentraut <pete...@gmx.net> writes: > > On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote: > >> Yeah, perhaps you're right. The main reason they were considered > >> separately is that we wanted to have them to be optimized via > >> pg_attribute.attnotnull, but my patch does away with the need for that > >> because it is maintained separately anyway. > > > Hmm, OK, but in any case you could have kept attnotnull and treated it > > as a kind of optimization that indicates whether you can derive > > not-nullability from existing CHECK constraints (which you can easily do > > in enough cases). > > Yes. I thought that was how we were going to do it, and I'm rather > distressed to hear of attnotnull going away. Even if there were not a > performance reason to keep it (and I'll bet there is), you can be sure > that removing that column will break a lot of client-side code. See > recent complaints about Robert removing relistemp, which has only been > around for a release or two. attnotnull goes back to the beginning, > more or less.
Err, obviously I didn't express myself very well. I am not removing the column. What I tried to say is that we no longer need to optimize the representation of NOT NULL as separate entities from CHECK constraints, because attnotnull is maintained separately from the pg_constraint entries. In other words, from that point of view, representing NOT NULL as CHECK is not a problem from a performance POV, because it is already taken care of by letting attnotnull continue to represent them as a cache. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
