Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 022664760D3 for ; Wed, 2 Oct 2002 13:06:39 -0400 (EDT) Received: from candle.pha.pa.us (momjian.navpoint.com [207.106.42.251]) by postgresql.org (Postfix) with ESMTP id 2C41F47608D for ; Wed, 2 Oct 2002 13:06:37 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id g92H6Re29922; Wed, 2 Oct 2002 13:06:27 -0400 (EDT) From: Bruce Momjian Message-Id: <200210021706.g92H6Re29922@candle.pha.pa.us> Subject: Re: indexing on char vs varchar In-Reply-To: <004101c26a32$3bce7390$0c00000a@bethvizx> To: Beth Gatewood Date: Wed, 2 Oct 2002 13:06:27 -0400 (EDT) Cc: pgsql-sql@postgresql.org X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/19 X-Sequence-Number: 9737 We store all the text/char/varchar types with the length at the front so we don't have such optimizations. We do have "char", in quotes, which is a single character, but that's about it. --------------------------------------------------------------------------- Beth Gatewood wrote: > Hi- > > This is more just trying to understand what is going on under the hood of > pgsql. I have read through the archives that there is no difference between > index on char, varchar or text. I am wondering why? I understand all the > arguments about saving space but I am specifically asking about index > performance and wondering about the underworkings of indices based on char > and varchar. > > Othe RDBMS have clear leanings that indexing on chars are a better way to > go. > > In MySQL this is due to a static table characteristics > (http://www.mysql.com/doc/en/Static_format.html) and speed for an index > look-up (row number X row length). and the ease to read a constant number of > records with each disk. > > In the case of Oracle, the suggestion for char is based on if using > varchar2 that takes 5 char and then there is a subsequent update to this > field to now take 20 char, but now the record can not grow physically...so > they essentially mark the old one as deleted and create a new record at the > top (in an entirely new block) but the problem is that the index points to > the deleted block...so the index has to query the old block and then the > new....(info from: > http://groups.google.com/groups?q=oracle+char+vs+varchar+index&hl=en&lr=&ie= > UTF-8&oe=UTF-8&selm=3a791aa3%40news.iprimus.com.au&rnum=1) > > Thanks for explaining this to me.... > -Beth > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073