1 char in the world

TEXT vs "char" ... vs BOOLEAN

I am porting from Informix to PG.  In doing so, I had to pick some data
types for fields, and began wondering about the performance of char/text
fields with one character.  For example, I have a field which has one of
the following values/states: {'A', 'D', 'F', 'U'}.  Since CHAR(n),
VARCHAR, and TEXT are all supposed to have the same performance
according to the docs, it seems that they will all perform the same.
For this reason, I did not squabble over which one of these to use.
However, since "char" is implemented differently, I thought I would
compare it to one of the others.  I chose to pit TEXT against "char".

Test query = explain analyze select count(*) from table where onechar='D';
Table size = 512 wide [mostly TEXT] * 400000 rows
Performance averages:
  "char"  44ms
  TEXT    63ms

This seems somewhat reasonable, and makes me want to use "char" for my
single-char field.  Does everyone else find this to be reasonable?  Is
this pretty much the behavior I can expect on extraordinarily large
tables, too?  And, should I worry about things like the backend
developers removing "char" as a type later?

--

This naturally led me to another question.  How do TEXT, "char", and
BOOLEAN compare for storing t/f values.  The test results I saw were
surprising.

Test query=
  "char"/TEXT: explain analyze select count(*) from table where bool='Y';
  boolean:    explain analyze select count(*) from table where bool=true;
Table size (see above)
Performance averages:
  TEXT    24ms
  BOOLEAN 28ms
"char"   17ms

Why does boolean rate closer to TEXT than "char"?  I would think that
BOOLEANs would actually be stored like "char"s to prevent using the
extra 4 bytes with TEXT types.

Based on these results, I will probably store my booleans as "char"
instead of boolean.  I don't use stored procedures with my application
server, so I should never need my booleans to be the BOOLEAN type.  I
can convert faster in my own code.

--

NOTE: the above tests all had the same relative data in the different
fields (what was in TEXT could be found in "char", etc.) and were all
indexed equally.


Thanks!

--
Matt Mello