You can use a hash index for this. It's drawback is that it is not
yet WAL enabled and if your DB crashes you will need to rebuild the
index to fix the corruption. It works well(only) with equality
searches. If it is a scenario where you must have WAL, use a
function index based on the hash of the string.
Cheers,
Ken
On Tue, Nov 30, 2010 at 10:57:31AM -0700, Rob Sargent wrote:
> If the performance against an index doesn't cut it, we would be forced
> to choose just such an implementation, but if pg can do it straight up
> that would be less work for us. A good thing, to be sure.
>
> On 11/30/2010 10:50 AM, jose wrote:
> > Why don't you use some type of hash like md5 for indexing ?
> >
> > 2010/11/30 Rob Sargent <robjsargent@gmail.com>:
> >> Were we to create a table which included a text field for a small block
> >> of xml (100-1000 chars worth), would an index on that field be useful
> >> against exact match queries?
> >>
> >> We're wondering if a criterion such as "where 'a string expected to be
> >> of size range 100 to 500' = tabelWithStrings.stringSearched" would make
> >> good use of an index on "stringSearched" column.
> >>
> >> The key is that there will only be exact match queries.
> >>
> >> Thanks for your thoughts.
> >>
> >>
> >>
> >> --
> >> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-sql
> >>
> >
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql
>
