Re: index row size exceeds btree maximum, 2713 - - Mailing list pgsql-general

From Scott Marlowe
Subject Re: index row size exceeds btree maximum, 2713 -
Date
Msg-id 1121720146.8208.346.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: index row size exceeds btree maximum, 2713 - Solutions?  (Dan Armbrust <daniel.armbrust.list@gmail.com>)
List pgsql-general
On Mon, 2005-07-18 at 15:17, Dan Armbrust wrote:
> We have built a Model for terminologies that we call The Lexical Grid
> (more info http://informatics.mayo.edu/LexGrid/index.php)
>
> LexGrid has multiple backend data storage mechanisms, including LDAP
> and SQL.  We do our best to remain implementation independent - our
> SQL implementations, for example can run against MS Access, DB2, MySQL
> and PostgreSQL.
>
> I'm currently trying to load a new terminology into a PosgreSQL
> backend, and arrived at this error because it happens to have a couple
> of very large data values that get mapped into the 'propertyvalue'
> field.

Well, if you're trying to maintain compatibility to multiple backends,
then requiring a non-standard block size is going to be a big
non-starter for most folks running postgresql.  Very few, if any users,
are going to be willing to install a version of postgresql setup that
way just because of one program's needs.

Does this need to be a unique index for any reason?  If so, then an
md5(propertyvalue) would give you that.  If not, then you could make a
partial index like so:

create index yada_dx on yada (propertyvalue) where
length(propertybalue)<100;

But that would require you to add "where length(propertyvalue)<100" onto
your queries to use the index, I believe.

OTOH, this may be the time to use a hash index.

pgsql-general by date:

Previous
From: "Guy Rouillier"
Date:
Subject: Re: How to find the number of rows deleted
Next
From: Dan Armbrust
Date:
Subject: Re: index row size exceeds btree maximum, 2713 - Solutions?