Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0037113
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 03. Procurement managementminorN/A2017-10-19 10:222018-03-14 12:38
ReportervmromanosView Statuspublic 
Assigned ToAtulOpenbravo 
PrioritynormalResolutionopenFixed in Version
StatusnewFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0037113: Index clean up in C_Order table

DescriptionC_ORDER_DOCNO is not needed because C_ORDER_DOCUMENTNO_ID also indexes by DOCUMENTNO as first column.

In C_ORDER_CLIENT_ORG_DATE_DOCNO we can remove AD_CLIENT_ID column because in most of the cases all the orders in the system belong to the same client. This will reduce index size and will improve performance.
Steps To ReproduceNA
Proposed SolutionAttached (remember to export database after applying it)
TagsPerformance
Attached Filesdiff file icon order_index_review.diff [^] (1,036 bytes) 2017-10-19 10:22 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0035912 closedSandrahuguet Has no sense to have an index with ad_client_id at fist column 

-  Notes
(0099959)
shuehner (administrator)
2017-10-19 12:02

for 2nd index (remove ad_client_id) -> marked as related with issue where we did same change already in 2 other tables (for similar reason)

for 1st index:
- As both indexes are not unique functionally they are equivalent
- However for performance + size the 'single' column one is still better than combined one.

Example for but database with 84M orders:
- c_order_docno 2.592MB size
- c_order_documentno_id 6332MB size

Note: that combined one we need for grid ordering anyway

So in practice not just delete -> better but balance:
- is perf improvement for queries not needing _id part worth having the overhead of
- 2.5gb space + overhead of maintaining that idx

I tend to say not worth having both but don't have hard numbers ready.

- Issue History
Date Modified Username Field Change
2017-10-19 10:22 vmromanos New Issue
2017-10-19 10:22 vmromanos Assigned To => Triage Finance
2017-10-19 10:22 vmromanos File Added: order_index_review.diff
2017-10-19 10:22 vmromanos Modules => Core
2017-10-19 10:22 vmromanos Triggers an Emergency Pack => No
2017-10-19 10:28 vmromanos Target Version => 3.0PR18Q1
2017-10-19 10:39 vmromanos Tag Attached: Performance
2017-10-19 11:55 shuehner Relationship added related to 0035912
2017-10-19 12:02 shuehner Note Added: 0099959
2017-10-23 12:56 dmiguelez Assigned To Triage Finance => AtulOpenbravo
2018-02-20 12:44 vmromanos Target Version 3.0PR18Q1 => 3.0PR18Q1.1
2018-03-14 12:38 aferraz Target Version 3.0PR18Q1.1 =>


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker