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, drin
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 inser
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, ha
Patrick,
First off, thanks for posting this solution! I love to see a new demo of The
Power of Postgres(tm) and have been wondering about this particular problem
since it came up on IRC.
> The array method works quite nicely, especially for the
> columns like "languages" and "seeking" that are
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:
dati
Patrick Clery <[EMAIL PROTECTED]> writes:
> PLAN
> -
> Limit
I have currently implemented a schema for my "Dating Site" that is storing
user search preferences and user attributes in an int[] array using the
contrib/intarray package (suggested by Greg Stark). But there are a few
problems.
a) query_int can't be cast to int4.
b) query_int ca
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 attrib
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 dist
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
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
Patrick Clery wrote:
I'm working on a dating/personals/match-making site, that has used many
different methods of "match-making", t
11 matches
Mail list logo
