Thread: Efficiency of indexes on CHAR(n) and VARCHAR(n)
I've heard that doing indexes on CHAR(n) and VARCHAR(n) fields are dog slow. But that's mainly been with the commercial databases- Sybase and Oracle. Is this true with Postgres as well? Or, to put it more specifically, is it true enough that it is worthwhile for me to calculate the hash values of the CHAR fields and put the index there (I don't need to do selects using 'LIKE'). This means more complexity and higher maintainance than just slapping an index on the string field. Thanks, Brian
On 5/4/06 1:06 PM, "Brian Hurt" <bhurt@janestcapital.com> wrote: > I've heard that doing indexes on CHAR(n) and VARCHAR(n) fields are dog > slow. But that's mainly been with the commercial databases- Sybase and > Oracle. Is this true with Postgres as well? > > Or, to put it more specifically, is it true enough that it is worthwhile > for me to calculate the hash values of the CHAR fields and put the index > there (I don't need to do selects using 'LIKE'). This means more > complexity and higher maintainance than just slapping an index on the > string field. Sounds like you probably want to try using the indexing within postgres first and PROVE that you need to do something different before you try to implement your own. Doing otherwise might be a case of premature optimization without any evidence. I have tables of >25M rows with string indices that perform quite adequately for me. Sean