Waiting for 9.2 – More rewrite-less ALTER TABLE ALTER TYPEs

Three patches for you today, all committed by Robert Hass:

  • On 7th of February, patch:
    Add a transform function for numeric typmod coercisions.
     
    This enables ALTER TABLE to skip table and index rebuilds when a column
    is changed to an unconstrained numeric, or when the scale is unchanged
    and the precision does not decrease.
     
    Noah Misch, with a few stylistic changes and a fix for an OID
    collision by me.
  • also on 7th, patch:
    Add a transform function for varbit typmod coercisions.
     
    This enables ALTER TABLE to skip table and index rebuilds when the
    new type is unconstraint varbit, or when the allowable number of bits
    is not decreasing.
     
    Noah Misch, with review and a fix for an OID collision by me.
  • and a day later final patch:
    Add transform functions for various temporal typmod coercisions.
     
    This enables ALTER TABLE to skip table and index rebuilds in some cases.
     
    Noah Misch, with trivial changes by me.

Continue reading Waiting for 9.2 – More rewrite-less ALTER TABLE ALTER TYPEs

Waiting for 9.1 – Rewrite-less changing types of column

On 12th of February, Robert Haas committed patch:

Teach ALTER TABLE .. SET DATA TYPE TO avoid SOME TABLE rewrites.
 
WHEN the OLD TYPE IS BINARY coercible TO the NEW TYPE AND the USING     
clause does NOT CHANGE the COLUMN contents, we can avoid a FULL TABLE
rewrite, though any indexes ON the affected COLUMNS will still need
TO be rebuilt.  This applies, FOR example, WHEN changing a VARCHAR
COLUMN TO be OF TYPE text.
 
The prior coding assumed that the SET OF operations that force a
rewrite IS identical TO the SET OF operations that must be propagated
TO TABLES making USE OF the affected TABLE's rowtype.  This is
no longer true: even though the tuples in those tables wouldn't
need TO be modified, the DATA TYPE CHANGE invalidate indexes built
USING those composite TYPE COLUMNS.  Indexes ON the TABLE we're
actually modifying can be invalidated too, of course, but the
existing machinery is sufficient to handle that case.
 
Along the way, add some debugging messages that make it possible
to understand what operations ALTER TABLE is actually performing
in these cases.                                                      
 
Noah Misch and Robert Haas

Later on, on 15th, he committed second patch with few more cases where rewrite can be avoided.

Continue reading Waiting for 9.1 – Rewrite-less changing types of column

CHAR(x) vs. VARCHAR(x) vs. VARCHAR vs. TEXT – UPDATED 2010-03-03

UPDATE

Please read also about this change in Pg 9.1, and this change in Pg 9.2 posts, as they explain that since Pg 9.1 some of the limitations listed in this post are no longer there.

END OF UPDATE

Fight!

But more seriously – people tend to use various data types, and there have been some myths about them, so let's see how it really boils down.

First of all – All those data types are internally saved using the same C data structure – varlena.

Thanks to this we can be nearly sure that there are no performance differences. Are there no performance differences in reality? Let's test.

Continue reading CHAR(x) vs. VARCHAR(x) vs. VARCHAR vs. TEXT – UPDATED 2010-03-03

lpad() and rpad() gotcha

I was lately writing some program for a client of mine, which used UPC codes matching.

Since the codes are given in various ways, there was decision to pad the codes with leading zeros – up to 12 characters.

The code has been done, and worked like this:

# SELECT lpad('123456789', 12, '0');
     lpad
--------------
 000123456789
(1 ROW)

Continue reading lpad() and rpad() gotcha