Thank you for the answer!
Sure, the possiblity of having a separate column for each flag was
considered, but a common columnn is preferred -- I do not remember
exactly why. (I do not directly make that decision.) I guess the main
reason is that adding new columns to the table complicates the upgrade
procedure with our existing customer base.
Thank you again!
Peter
Michael Fuhr wrote:
> On Mon, Jan 23, 2006 at 08:00:01PM +0100, Kovcs Pter wrote:
>
>>Are indexes on VARCHAR columns used with the LIKE operator, and if so,
>>how efficiently are they used?
>>
>>I can imagine that using indexes can be easy with the starting literal
>>characters up to the first percent sign such as in:
>>
>>LIKE 'ZOE%QQWE%'
>>
>>But, after the first % sign, things can get more difficult.
>
>
> The planner can use an index on the starting literal characters;
> how "difficult" the query becomes after that depends on how
> discriminating those initial characters are. If values matching
> the initial characters comprise a small fraction of the table then
> the query will probably use an index and be fast, but if they
> comprise a large fraction of the table, or if the search string
> starts with a wildcard, then you'll get a sequential scan, which
> might be slow.
>
>
>>The reason I am asking is that we are thinking about discriminating
>>between rows of a table based on a VARCHAR column containing various
>>one-character "flags". We could then use the LIKE operator for
>>formulating filter conditions.
>
>
> Have you considered putting each flag in a separate column and
> indexing those columns? If you're using 8.1 the planner would
> probably use bitmap index scans and come up with a fast plan
> regardless of which columns you restrict on. And performance issues
> aside, some people would consider that a better design. However,
> a disadvantage might be that your queries would be more complex.
>
