| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Rob <postgresql(at)mintsoft(dot)net> | 
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: CHAR vs NVARCHAR vs TEXT performance | 
| Date: | 2019-04-29 17:43:57 | 
| Message-ID: | 30249.1556559837@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Rob <postgresql(at)mintsoft(dot)net> writes:
> Basically, if a table exists with a PK which is CHAR(n) and a query is
> sent with VARCHAR or CHAR then it uses an Index Scan. If the query is
> sent with TEXT as the type then postgresql casts the column to TEXT
> (rather than the value to CHAR) and it does a Seq Scan.
Yeah, this is an artifact of the fact that text is considered a
"preferred type" so it wins out in the parser's choice of which
type to promote to.  See
https://www.postgresql.org/docs/current/typeconv-oper.html
> I guess the root question is: is TEXT supposed to be identical to 
> VARCHAR in all scenarios?
It's not for this purpose, because varchar isn't a preferred type.
FWIW, my recommendation for this sort of thing is almost always
to not use CHAR(n).  The use-case for that datatype pretty much
disappeared with the last IBM Model 029 card punch.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashwin Agrawal | 2019-04-29 17:44:00 | Re: Race conditions with checkpointer and shutdown | 
| Previous Message | Tom Lane | 2019-04-29 17:35:59 | Re: Race conditions with checkpointer and shutdown |