Re: Faster data type for one-length values
От | André Volpato |
---|---|
Тема | Re: Faster data type for one-length values |
Дата | |
Msg-id | 4654520F.6080701@ecomtecnologia.com.br обсуждение исходный текст |
Ответ на | Re: Faster data type for one-length values (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Faster data type for one-length values
|
Список | pgsql-general |
Tom Lane escreveu: <blockquote cite="mid20197.1179929832@sss.pgh.pa.us" type="cite"><pre wrap="">André Volpato <a class="moz-txt-link-rfc2396E" href="mailto:andre.volpato@ecomtecnologia.com.br"><andre.volpato@ecomtecnologia.com.br></a>writes: </pre><blockquotetype="cite"><pre wrap="">I need to store one-length values like '1', '2', '3' or '4' . </pre></blockquote><prewrap=""> </pre><blockquote type="cite"><pre wrap="">Today, this field is indexed with btree and isof type smallint (int2). How much performance will be improved if I change it to "char" (1 byte length) ? </pre></blockquote><pre wrap=""> The improvement will be zero. Because of alignment restrictions, you don't save any space from making an index entry smaller than 4 bytes. If you have several such fields adjacent in a table row, making them all narrower can save space, but it doesn't help for standalone index entries. regards, tom lane </pre></blockquote><br /> Tom,<br /><br /> The ammount of space saved seems pretty clear to me.<br /><br /> What are you saying is that the index behaviour is the same, for all types smaller than 4 bytes ? For queryperformance, in a search is based on that standalone indexed field, would be any difference using :<br /> a. char(1); b. int2; c. "char"<br /><br /> Thanks again !<br /><br /><pre class="moz-signature" cols="72">-- []´s, André Volpato ECOM Tecnologia Ltda <a class="moz-txt-link-abbreviated" href="mailto:andre.volpato@ecomtecnologia.com.br">andre.volpato@ecomtecnologia.com.br</a> (41) 3014 2322</pre>
В списке pgsql-general по дате отправления: