-
-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize EAV collections #911
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve. Would be great to drop the column and index and save some db memory as well but this would likely break someone's code somewhere. I don't see an issue with this change though.
@Sekiphp Do you agree with the changes? Please update PR if so. Thanks! |
Bump @Sekiphp. Looks like a good suggestion from @colinmollenhour and pretty simple. Looks like a good change to implement. |
Your suggestion implemented @colinmollenhour ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
fba9ac8
to
7f216f1
Compare
Finally fixed @colinmollenhour @joshua-bn @tmotyl |
It's been a while since I looked at this so I might've lost some knowledge here. For the entity tables like customer, catalog, etc, the entity_type_id will always be the same. For the eav_entity table (I don't think anyone ever uses that table) this does matter. The condition seems backwards then. If it is the default table, we should add the entity_type_id filter. If it is not then there's no need, right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshua-bn is right, I had the logic backwards! Doh!
So the right solution is?:
@colinmollenhour I did some changes, because: |
@Sekiphp it should be the table, not the model. I think this is what we're looking for:
|
I'm not sure, what is the status of this PR? |
With a little changes in code as requested we can merge this PR . |
As Colin wrote, changes were implemented and/or he noticed his comment was wrong
The SQL queries with our MariaDB 10.7:
I don't see problems at localhost with this change. |
Co-authored-by: Colin Mollenhour <colin@mollenhour.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested.
So I tested the wrong version at localhost, but I didn't see any bad changes... |
this one is approved for merging, is everybody comfortable with this? |
I have this in production a month now. No issue so far. |
Some DB background
Overview
In cases when Magento collections are extended from
Mage_Eav_Model_Entity_Collection_Abstract
there are filtering byentity_type_id
but for example for customer entity_type_id is always 1 (viz. screenshot)But this conditions slow down multiple queries and I think, that at this time is abandoned using entity_type_id for most of queries.