Re: [Solved] SQL Server to PostgreSQL
От | Tom Lane |
---|---|
Тема | Re: [Solved] SQL Server to PostgreSQL |
Дата | |
Msg-id | SAK.2000.09.03.spadtemb@acr1 обсуждение исходный текст |
Ответ на | Re: [Solved] SQL Server to PostgreSQL (Ian Turner <vectro@pipeline.com>) |
Список | 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 по дате отправления: