| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Richard Huxton <dev(at)archonet(dot)com> |
| Cc: | KÖPFERL Robert <robert(dot)koepferl(at)sonorys(dot)at>, "'dpandey(at)secf(dot)com'" <dpandey(at)secf(dot)com>, pgsql-general(at)postgresql(dot)org, 'PostgreSQL' <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: [SQL] index row size 2728 exceeds btree maximum, 27 |
| Date: | 2005-06-02 16:35:42 |
| Message-ID: | 20050602163542.GA23150@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-sql |
On Thu, Jun 02, 2005 at 13:40:53 +0100,
Richard Huxton <dev(at)archonet(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2005-06-02 17:00:17 | Re: [SQL] index row size 2728 exceeds btree maximum, 27 |
| Previous Message | Alexandre Biancalana | 2005-06-02 16:25:31 | Re: postgresql 8 abort with signal 10 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2005-06-02 17:00:17 | Re: [SQL] index row size 2728 exceeds btree maximum, 27 |
| Previous Message | Tom Lane | 2005-06-02 16:32:09 | Re: getting details about integrity constraint violation |