No. No gain at all. The manual explicitly states:
Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While
character(n)
has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in factcharacter(n)
is usually the slowest of the three because of its additional storage costs. In most situationstext
orcharacter varying
should be used instead.
char(n)
is a largely outdated, useless type. Stick with varchar(n)
. If you don't need to enforce the length, varchar
or text
would be a tiny bit faster.
You won't be able to measure a difference.
Also, if all strings are exactly 36 characters in length, there is no storage saving either way, not even a minuscule one. Both have exactly the same size on disk and in RAM. You can test with pg_column_size()
(on an expression and on a table column).
Related:
You didn't ask for other options, but I'll mention two:
COLLATION
- unless you are running your DB with the "C" collation. Collation is often overlooked and possibly expensive. Since your strings don't seem to be meaningful in a natural language, there is probably no point in followingCOLLATION
rules. Related:- How do I efficiently get "the most recent corresponding row"?
- EXECUTE within function not using index?
Extensive benchmark comparing (among other) the effect of COLLATE "C"
on performance:
UUID, obviously. Your string suspiciously looks like a UUID (32 hex digits plus 4 delimiters). It would be much more efficient to store these as actual
uuid
data type, which is faster in multiple ways and only occupies 16 bytes (as opposed to 37 bytes for eitherchar(36)
orvarchar(36)
.COLLATION
would be irrelevant, too.SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid
This may be helpful (last chapters):