On Nov 23, 6:42 pm, Christophe Pettus <x...@thebuild.com> wrote:
> On Nov 23, 2010, at 5:40 PM, sh...@bogomip.com wrote:
>
> > Without test data I'm not sure where the trade offs are with the
> > following. However it should improve the ability to look up items
> > that reference a certain set of keys as well as easily check to see if
> > a set already exists. This should also help reduce the number of rows
> > in a reference table.
>
> It definitely does that. The downsides are:
>
> 1. Selects that are looking for a particular individual value ("all items
> that reference user 1") are going to be a sequential scan.
Since you've noticed it I have to ask.. since I didn't think it would
be any different.. how does this differ from the current Django
method?
> 2. You might get collisions on the adler32 function in real life; I'm not
> familiar enough with that particular function.
Oh.. it's pretty easy to get a collision.. only takes around 1000
iterations of random sets in my case. Thats the point of adding a 0
padded number, starting at 0, to the end of the adler32 result.
Allows for padded length amount of collisions.
> If you are using PostgreSQL, you might look at using intarray or hstore
> fields instead; those have the same advantages you enumerate, but you can
> also index on them in ways that will speed up searches for individual values.
Outside of the ORM I'll play around with this.
- Shane
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
