Hi Jason

Can you share your index definitions? Might make it easier to grok the 
situation.

Cheers

— 
Pat

On 31 Oct 2013, at 4:17 am, Jason Ivers <[email protected]> wrote:

> I have a table products (414 records in my dev environment), which have many 
> local_releases (12296 records in dev).  Each local release also has a 
> territory associated with it (belongs_to).  The products model has_many 
> territories through local_releases.
> 
> All of the above tables have sequential ID's with no gaps.
> 
> If I index local_releases, with the product's attributes (title, etc.) as 
> indexed fields, the index builds in a reasonable amount of time (~30 seconds).
> 
> If I index products, with a field from local_releases (a date field) as an 
> attribute, it takes longer than I'm willing to wait (> 10 minutes).  I've 
> also tried indexing it, rather than adding it as an attribute, but that 
> doesn't seem to affect the speed.
> 
> If I index products, with the territory ID as an attribute (has_many through 
> local_releases), this completes in a reasonable (though slower than indexing 
> local_releases directly) amount of time.
> 
> The date field that I'm trying to add as an attribute IS indexed, and cannot 
> be null... I can't figure out why indexing the product instead of the 
> local_release causes it to essentially hang.  I don't particularly want to 
> index the local release, as any time I'm searching, I want the product, I 
> just need to be able to filter by the territory and date in the local_release 
> table.
> 
> Does anyone have any suggestions for me?  I'd really appreciate the help, as 
> right now I'm having to actually search local releases, then collect the 
> product_id, and search products where id in product_ids, which is a really 
> backwards way to approach this.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Thinking Sphinx" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/thinking-sphinx.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/thinking-sphinx.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to