In Postgres does the order of columns in a CREATE TABLE
statement impact performance? Consider the following two cases:
CREATE TABLE foo ( a TEXT, B VARCHAR(512), pkey INTEGER PRIMARY KEY, bar_fk INTEGER REFERENCES bar(pkey), C bytea );
vs.
CREATE TABLE foo2 ( pkey INTEGER PRIMARY KEY, bar_fk INTEGER REFERENCES bar(pkey), B VARCHAR(512), a TEXT, C bytea );
Will performance of foo2
be better than foo
because of better byte alignment for the columns? When Postgres executes CREATE TABLE
does it follow the column order specified or does it re-organize the columns in optimal order for byte alignment or performance?
The order of columns doesn't matter in creating tables in PostgreSQL, but it does matter sometimes in creating indexes in PostgreSQL.
Yes the number of columns will - indirectly - influence the performance. The data in the columns will also affect the speed.
Yes, column order does matter.
You are right that the result is the same no matter in which order the columns appear in the GROUP BY clause, and that the same execution plan could be used. The PostgreSQL optimizer just doesn't consider reordering the GROUP BY expressions to see if a different ordering would match an existing index.
Will the performance of
foo2
be better thanfoo
because of better byte alignment for the columns?
Yes, the order of columns can have a small impact on performance. Type alignment is the more important factor, because it affects the footprint on disk. You can minimize storage size (play "column tetris") and squeeze more rows on a data page - which is the most important factor for speed.
Normally it's not worth to bother. With an extreme example like in this related answer you get a substantial difference:
Type alignment details:
The other factor is that retrieving column values is slightly faster if you have fixed size columns first. I quote the manual here:
To read the data you need to examine each attribute in turn. First check whether the field is NULL according to the null bitmap. If it is, go to the next. Then make sure you have the right alignment. If the field is a fixed width field, then all the bytes are simply placed. If it's a variable length field (attlen = -1) then it's a bit more complicated. All variable-length data types share the common header structure
struct varlena
, which includes the total length of the stored value and some flag bits.
There is an open TODO item to allow reordering of column positions in the Postgres Wiki, partly for these reasons.
When Postgres executes a
CREATE TABLE
does it follow the column order specified or does it re-organize the columns in optimal order for byte alignment or performance?
Columns are stored in the defined order, the system does not try to optimize.
I fail to see any relevance of column order to TOAST tables like another answer seems to imply.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With