| From: | Sean Davis <sdavis2(at)mail(dot)nih(dot)gov> |
|---|---|
| To: | Brian Hurt <bhurt(at)janestcapital(dot)com>, <pgsql-novice(at)postgresql(dot)org> |
| Subject: | Re: Efficiency of indexes on CHAR(n) and VARCHAR(n) |
| Date: | 2006-05-04 17:14:27 |
| Message-ID: | C07FAEB3.B073%sdavis2@mail.nih.gov |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
On 5/4/06 1:06 PM, "Brian Hurt" <bhurt(at)janestcapital(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | operationsengineer1 | 2006-05-04 18:33:33 | SQL Order Question |
| Previous Message | Brian Hurt | 2006-05-04 17:06:10 | Efficiency of indexes on CHAR(n) and VARCHAR(n) |