Re: [Solved] SQL Server to PostgreSQL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ian Turner <vectro(at)pipeline(dot)com>, Jan Wieck <janwieck(at)Yahoo(dot)com>, Martin Christensen <knightsofspamalot-factotum(at)mail1(dot)stofanet(dot)dk>, pgsql-general(at)postgresql(dot)org
Subject: Re: [Solved] SQL Server to PostgreSQL
Date: 2000-10-15 03:32:22
Message-ID: 200010150332.XAA22535@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> Ian Turner <vectro(at)pipeline(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2000-10-15 03:33:42 Re: [Solved] SQL Server to PostgreSQL
Previous Message Bruce Momjian 2000-10-15 03:28:12 Re: [Solved] SQL Server to PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-10-15 03:33:42 Re: [Solved] SQL Server to PostgreSQL
Previous Message Bruce Momjian 2000-10-15 03:28:12 Re: [Solved] SQL Server to PostgreSQL