From: | Richard Troy <rtroy(at)ScienceTools(dot)com> |
---|---|
To: | Aleksander Kmetec <aleksander(dot)kmetec(at)intera(dot)si> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: index type for indexing long texts |
Date: | 2007-01-13 17:09:54 |
Message-ID: | Pine.LNX.4.33.0701130908190.18194-100000@denzel.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Aleksander Kmetec <aleksander(dot)kmetec(at)intera(dot)si> writes:
> > I'm looking for a solution for indexing long TEXT columns. We're currently using a HASH index, which can handle most
> > situations, but every now and then we need support for even longer texts.
>
> > One solution would be to create a functional index which would only use the first N chars of mycol, but then we'd have
> > to change several hundred occurences of "mycol = someval" with "(mycol = someval AND firstN(mycol) = firstN(someval))",
> > as well as update some SQL generators...
>
> > That's why I'd be interested to know if there are any index types available which store only the first N chars or use
> > some highly compressed form for storing index data, and then recheck any potential hits against the main table. And if
> > something like that does not exist yet, how difficult would it be to construct such a solution out of many "spare parts"
> > that come with PG?
>
Try moving where the hash takes place - ie, use your own hash function to
create the key.
RT
--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Amiel | 2007-01-13 17:40:41 | Re: Corrupt database? 8.1/FreeBSD6.0 |
Previous Message | Tom Lane | 2007-01-13 16:54:29 | Re: Corrupt database? 8.1/FreeBSD6.0 |