> Ian Turner <vectro@pipeline.com> writes:
> > Don't variable-length records incur a performance overhead?
>
> Only to the extent that the system can't cache offset information for
> later columns in that table. While someone evidently once thought that
> was worthwhile, I've never seen the column-access code show up as a
> particularly hot spot in any profile I've run. I doubt you could
> actually measure any difference, let alone show it to be important
> enough to be worth worrying about.
>
> In any case, char(n) will still do what you want for reasonable-size
> records. The TOAST code only kicks in when the total tuple size exceeds
> BLCKSZ/4 ... and at that point, compression is a good idea in any case.
My logic is that I use char() when I want the length to be fixed, like
2-letter state codes, and varchar() for others where I just want a
maximum allowed, like last name. I use text for arbitrary length stuff.
Tom is right that though there is a small performance difference, it is
better just to use the right type.
>
> Now that you mention it, though, doesn't TOAST break heapam's assumption
> that char(n) is fixed length? Seems like we'd better either remove that
> assumption or mark char(n) nontoastable. Any opinions which is better?
I am sure Jan handled that.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
