Another problem I should note is that when I first insert all the data into
the people_attributes table (the int[] table), the GiST index is not used:
THE INDEX:
people_attributes_search gist ((ARRAY[age, gender, orientation, children,
drinking, education,
ethnicity, eyecolor, haircolor,
Err... I REINDEX'ed it and it is now using the index. :)
I'd still appreciate if anyone could tell me why this needs to be
reindexed. Is the index not updated when the records are inserted?
On Wednesday 06 October 2004 12:55, I wrote:
Another problem I should note is that when I first insert
Patrick Clery [EMAIL PROTECTED] writes:
PART OF THE QUERY PLAN:
Index Scan using people_attributes_pkey on people_attributes pa (cost=0.00..5.32
rows=1 width=20)
Index Cond: (pa.person_id = outer.person_id)
Filter: (((ARRAY[age, gender, orientation, children, drinking,
Sorry I have taken this long to reply, Greg, but here are the results of the
personals site done with contrib/intarray:
The first thing I did was add a serial column to the attributes table. So
instead of having a unique constraint on (attribute_id,value_id), every row
has a unique value:
I'm working on a dating/personals/match-making site, that has used many
different methods of match-making, that all seem to be very slow. One I am
attempting now that seems to be an efficient method of storage, but not the
best for indexing, is using bitwise operators to compare one person's
Patrick Clery [EMAIL PROTECTED] writes:
Method 3 is the only one that used the index, but the only really acceptable
method here is Method 1.
My questions are...
- Is there any hope in getting this to use an efficient index?
- Any mathmaticians know if there is a way to reorder my
Patrick Clery [EMAIL PROTECTED] writes:
Here's the structure of the marital status table:
Also I find it very odd that you have a marital status table. marital status
is just one attribute of member. Do you expect to have more than one marital
status bitfield per member? How would you
Christopher Kings-Lynne wrote:
Sounds like you want a many-to-many table that maps user_ids to match_ids
Then you can put an index over (user_id, match_id) and the search will
be very fast.
Chris
If I understand you correctly, I believe I've tried this approach. While
matching on a single
