Re: [SQL] Full-Text-Indexing
От | Tom Lane |
---|---|
Тема | Re: [SQL] Full-Text-Indexing |
Дата | |
Msg-id | 15517.929206841@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Full-Text-Indexing (Alexander Schneider <alex@alexander-schneider.de>) |
Список | pgsql-sql |
Alexander Schneider <alex@alexander-schneider.de> writes: > 1) Why should I use "varchar(n)" instead of "text" though the space for a > varchar-field is larger than text (varchar: 4byte+n, text: 2byte+n)? Is > it more efficient for queries? Actually, both text and varchar have 4-byte overhead. There's no difference at all in the representation, and none to speak of in efficiency. The reason you'd use varchar() is if you have an application-defined restriction that the contents of the field may not exceed some particular length. In that case you say varchar(N), which both makes the intent visible and allows Postgres to enforce the requirement for you. If you don't have any particular upper bound in mind for the string length, use text type. Just for completeness: char(N) also has a 4-byte overhead ... rather unnecessarily, but that's how it's done at the moment. But there is a marginal (very marginal) efficiency gain in access, since the system knows that the field is always the same length --- that makes it easier to determine the locations of following fields in the same tuple. I think you'd pretty much only use char(N) when you have an application semantics restriction that the string length must be exactly N characters. For example, in US postal addresses the state abbreviation would be char(2). regards, tom lane
В списке pgsql-sql по дате отправления: