Thread: Re: [SQL] index row size 2728 exceeds btree maximum, 2713

-----Original Message-----
From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org]On Behalf Of Dinesh Pandey
Sent: Thursday, January 01, 2004 3:14 PM
To: Ramakrishnan Muralidharan; pgsql-general@postgresql.org; 'PostgreSQL'
Subject: Re: [SQL] index row size 2728 exceeds btree maximum, 2713

Hi,

 

One of the columns in primary key is of type “TEXT”. I am able to insert with small data, but for around 3000 characters it’s failing. How to handle that?

 

Thanks
Dinesh Pandey

---

From: Ramakrishnan Muralidharan [mailto:ramakrishnanm@pervasive-postgres.com]
Sent: Thursday, June 02, 2005 3:11 PM
To: dpandey@secf.com; pgsql-general@postgresql.org; PostgreSQL
Subject: RE: [SQL] index row size 2728 exceeds btree maximum, 2713

 

         Hi,

 

             The issue looks like your Index width exceeds the maximum width  of the index key limit, Please review the keys used in the index.

 

Regards,

R.Muralidharan

 

     

-----Original Message-----
From: pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org]On Behalf Of Dinesh Pandey
Sent: Thursday, June 02, 2005 12:35 PM
To: pgsql-general@postgresql.org; 'PostgreSQL'
Subject: [SQL] index row size 2728 exceeds btree maximum, 2713

TABLE

-----------+-----------------------+-----------

  Column    |         Type      

-----------+-----------------------+-----------

 scan_id    | bigint               

 host_ip    | character varying(15)

 port_num | integer              

 plugin_id  | integer               

 severity   | character varying(50)

 data       | text                 

Indexes:

    "pk_scanned_port_info" PRIMARY KEY, btree (scan_id, host_ip, port_num, plugin_id, severity, data)

 

 

On inserting record I am getting this error “index row size 2728 exceeds btree maximum, 2713”

 

How to solve this problem?

 

 

 

On Thu, Jun 02, 2005 at 17:48:47 +0530,
  Dinesh Pandey <dpandey@secf.com> wrote:
> Yes I am storing some "error messages" in data column, and the PK columns
> are party of search criteria.

If you need to be able to search based on the entire stored error message,
than you might try adding an indexed hash column to the table and using that
to speed up searches. You can still compare the full string in case you
have a hash collision, but those should be very rare.