| From: | Doug McNaught <doug(at)wireboard(dot)com> |
|---|---|
| To: | "Thalis A(dot) Kalfigopoulos" <thalis(at)cs(dot)pitt(dot)edu> |
| Cc: | Steve Micallef <stevenm(at)ot(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Unique rows without a key |
| Date: | 2001-06-14 15:09:12 |
| Message-ID: | m3vglzm73b.fsf@belphigor.mcnaught.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Thalis A. Kalfigopoulos" <thalis(at)cs(dot)pitt(dot)edu> writes:
> > Thanks for your help. However I was thinking more along the lines of using
> > the table itself as the index. Creating a hash column with all the other
> > columns as part of it still significantly increases my table size.
>
> It's not that much of an overhead especially if your table has many
> attributes. There is a function hashname() that will return an
> integer after hashing the text it takes as argument. I didn't find
> any documentation, but seems to work.
If it's not documented I'd worry about it going away in the future.
> Then you just add a unique index on hashval and you are done :-)
And if you get a hash collision? Going to disallow a perfectly
legitimate and unique row because of it?
-Doug
--
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time... --Dylan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thalis A. Kalfigopoulos | 2001-06-14 15:14:05 | Re: Unique rows without a key |
| Previous Message | Thalis A. Kalfigopoulos | 2001-06-14 15:05:06 | Re: Unique rows without a key |