Re: [Solved] SQL Server to PostgreSQL - Mailing list pgsql-general

From Tom Lane
Subject Re: [Solved] SQL Server to PostgreSQL
Date
Msg-id 7057.967957648@sss.pgh.pa.us
Whole thread Raw
In response to Re: [Solved] SQL Server to PostgreSQL  (Ian Turner <vectro@pipeline.com>)
Responses Re: [Solved] SQL Server to PostgreSQL  (Jan Wieck <janwieck@Yahoo.com>)
Re: [Solved] SQL Server to PostgreSQL  (Jan Wieck <janwieck@Yahoo.com>)
Re: [Solved] SQL Server to PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [Solved] SQL Server to PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Ron Chmara
Date:
Subject: Re: Increasing system speed by using -F option
Next
From: Jurgen Defurne
Date:
Subject: Re: Increasing system speed by using -F option