Re: [SQL] index row size 2728 exceeds btree maximum, 27
От | Jaime Casanova |
---|---|
Тема | Re: [SQL] index row size 2728 exceeds btree maximum, 27 |
Дата | |
Msg-id | c2d9e70e0506020848667a6e28@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [SQL] index row size 2728 exceeds btree maximum, 27 (Richard Huxton <dev@archonet.com>) |
Список | pgsql-general |
On 6/2/05, Richard Huxton <dev@archonet.com> wrote: > KÖPFERL Robert wrote: > > To me it seems that the definer of this table missed the concept index ... > > or the concept database > > One usually looks up data using a key, but if the whole row is the key, what > > data shall be looked up. > > > So short story long: Remove data from your index. The data column seems > > like the data to be looked up using the key > > (scan_id, host_ip, port_num, plugin_id, severity) or even less. > > Postgres is able to take several indices over distinct columns into account. > > Thus reducing the possible candidates to a hand full. > > So several indices are also an option > > Actually, Dinesh didn't mention he was using this for the speed of > lookup. He'd defined the columns as being the PRIMARY KEY, presumably > because he feels they are/should be unique. Given that they are rows > from a logfile, I'm not convinced this is the case. > If this a log he will need a timestamp field to be usefull, making that field part of the primary key and letting the data out of the primary has more sense to me. -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
В списке pgsql-general по дате отправления: