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.
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?
regards, tom lane