Re: [SQL] index row size 2728 exceeds btree maximum, 27
От | Richard Huxton |
---|---|
Тема | Re: [SQL] index row size 2728 exceeds btree maximum, 27 |
Дата | |
Msg-id | 429F3B21.9020209@archonet.com обсуждение исходный текст |
Ответ на | Re: [SQL] index row size 2728 exceeds btree maximum, 27 (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: [SQL] index row size 2728 exceeds btree maximum, 27
|
Список | pgsql-general |
Bruno Wolff III wrote: > On Thu, Jun 02, 2005 at 13:40:53 +0100, > Richard Huxton <dev@archonet.com> wrote: > >>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. > > > Even for case you could still use hashes. The odds of a false collision > using SHA-1 are so small that some sort of disaster is more likely. > Another possibility is if there are a fixed number of possible messages, > is that they could be entered in their own table with a serail PK and > the other table could reference the PK. Certainly, but if the text in the logfile row is the same, then hashing isn't going to make a blind bit of difference. That's the root of my concern, and something only Dinesh knows. -- Richard Huxton Archonet Ltd
В списке pgsql-general по дате отправления: