Message-ID: <46560264.2020406@emolecules.com>
Date: Thu, 24 May 2007 14:23:48 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070221)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: LIKE search and performance
References: <009501c79d4c$445428f0$0b00a8c0@mpsro.dom>	
	<88daf38c0705230905u1a981102k691b47bd36011a80@mail.gmail.com>	
	<4655DE75.4080506@mansionfamily.plus.com>
	<4655E64B.5050503@hagander.net>	
	<4655FB8A.1040707@mansionfamily.plus.com>
	<1180040560.31471.262.camel@archimedes>
In-Reply-To: <1180040560.31471.262.camel@archimedes>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Lewis wrote:

> PG could scan the index looking for matches first and only load the
> actual rows if it found a match, but that could only be a possible win
> if there were very few matches, because the difference in cost between a
> full index scan and a sequential scan would need to be greater than the
> cost of randomly fetching all of the matching data rows from the table
> to look up the visibility information.  

Just out of curiosity: Does Postgress store a duplicate of the data in the index, even for long strings?  I thought indexes only had to store the string up to the point where there was no ambiguity, for example, if I have "missing", "mississippi" and "misty", the index only needs "missin", "missis" and "mist" in the actual index.  This would make it impossible to use a full index scan for a LIKE query.

Craig