On Thu, Jan 26, 2012 at 8:51 PM, Linus Pettersson <
linus.petters...@gmail.com> wrote:
> This query is only to get the appropriate Categories & Subcategories.
> There are 5 Categories and 45 Subcategories.
>
> My products are imported from webshops which are using different
> categories for the sa
This query is only to get the appropriate Categories & Subcategories. There
are 5 Categories and 45 Subcategories.
My products are imported from webshops which are using different categories
for the same things ("tshirt", "t-shirts", "t-shirt", "short sleeved
shirts" may all be the same). To co
On Thu, Jan 26, 2012 at 6:37 PM, Peter Vandenabeele
wrote:
> On Thu, Jan 26, 2012 at 6:15 PM, Linus Pettersson <
> linus.petters...@gmail.com> wrote:
>
>> Hi
>>
>> I tested to remove the .order(...) part and indeed, the query time goes
>> down to ~100ms. However, it doesn't help to add indices, at
On Thu, Jan 26, 2012 at 6:15 PM, Linus Pettersson <
linus.petters...@gmail.com> wrote:
> Hi
>
> I tested to remove the .order(...) part and indeed, the query time goes
> down to ~100ms. However, it doesn't help to add indices, at least not as I
> did :)
>
> add_index :categories, :name
> add_index
Also, another reason for the query that I forgot to mention is that if a
user filters the products for female products only for instance, it should
only show categories and subcategories that contains products for that
gender.
The gender is specified in the products table...
--
You received t
Hi
I tested to remove the .order(...) part and indeed, the query time goes
down to ~100ms. However, it doesn't help to add indices, at least not as I
did :)
add_index :categories, :name
add_index :subcategories, :name
Did some more testing and if I keep the .order... but don't join the
produc
On Wed, Jan 25, 2012 at 8:51 PM, Linus Pettersson <
linus.petters...@gmail.com> wrote:
> Well, maybe it's not necessary... It is the slowest of my queries as far
> as I can see anyway.
>
> I'm using Rails 3.2 and I have enabled automatic EXPLAIN on slow queries
> (>0.5s). This query is currently b
Well, maybe it's not necessary... It is the slowest of my queries as far as
I can see anyway.
I'm using Rails 3.2 and I have enabled automatic EXPLAIN on slow queries
(>0.5s). This query is currently being "explained" in my console when I run
it on my localhost. "SQL (556.5ms) ..."
556.5ms see
On Wed, Jan 25, 2012 at 8:20 PM, Linus Pettersson <
linus.petters...@gmail.com> wrote:
> Thank you. I have added the generated SQL to the snipt in my first post.
>
> Regarding the EXPLAIN ANALYZE, can I somehow run that on Heroku? I'm using
> their shared database so I don't have access to any psq
Thank you. I have added the generated SQL to the snipt in my first post.
Regarding the EXPLAIN ANALYZE, can I somehow run that on Heroku? I'm using
their shared database so I don't have access to any psql console...
I did run it on my local machine though. The thing is that it differs in
databa
Would probably help if you posted the generated SQL as well as the
output of EXPLAIN ANALYZE, which shows not just what the planner
thinks the costs are, but what the costs actually were.
You could also try running ANALYZE on the tables in question, or
ANALYZE VERBOSE and checking if the estimates
11 matches
Mail list logo
