Обсуждение: 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?
Dinesh Pandey wrote: > -----------+-----------------------+----------- > 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" Well - the error message is clear enough. The question is, what to do. Without knowing what the table "means", it's difficult to say what the primary-key should be, but it seems unlikely to include an unlimited-length text-field called "data". If the data itself doesn't offer any suitable candidate keys (as can well be the case) then common practice is to generate a unique number and use that as an ID - in PostgreSQL's case by use of the SERIAL pseudo-type. Does that help? -- Richard Huxton Archonet Ltd
I am inserting some log messages in the column "data". (Basically I am inserting records from reading an xml file) In the PRIMARY KEY, btree (scan_id, host_ip, port_num, plugin_id, severity, data) data is of type TEXT and can contain long string values. The question is how to remove this error "index row size 2728 exceeds btree maximum, 2713" by increasing the btree size? The big problem is "I can not add any additional column in this table." Thanks Dinesh Pandey -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Richard Huxton Sent: Thursday, June 02, 2005 3:29 PM To: dpandey@secf.com Cc: pgsql-general@postgresql.org; 'PostgreSQL' Subject: Re: [GENERAL] index row size 2728 exceeds btree maximum, 2713 Dinesh Pandey wrote: > -----------+-----------------------+----------- > 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" Well - the error message is clear enough. The question is, what to do. Without knowing what the table "means", it's difficult to say what the primary-key should be, but it seems unlikely to include an unlimited-length text-field called "data". If the data itself doesn't offer any suitable candidate keys (as can well be the case) then common practice is to generate a unique number and use that as an ID - in PostgreSQL's case by use of the SERIAL pseudo-type. Does that help? -- Richard Huxton Archonet Ltd ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
Dinesh Pandey wrote: > I am inserting some log messages in the column "data". (Basically I am > inserting records from reading an xml file) > > In the PRIMARY KEY, btree (scan_id, host_ip, port_num, plugin_id, severity, > data) data is of type TEXT and can contain long string values. I'm still not convinced that "data" makes a sensible part of the primary key. Can you give an example of "data" and explain why the whole value determines unique-ness? > The question is how to remove this error "index row size 2728 exceeds btree > maximum, 2713" by increasing the btree size? > > The big problem is "I can not add any additional column in this table." Why not? -- Richard Huxton Archonet Ltd