Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0033119 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| backport | [Retail Modules] Web POS | major | have not tried | 2016-06-02 18:05 | 2016-07-05 18:45 | |||
| Reporter | shuehner | View Status | public | |||||
| Assigned To | Retail | |||||||
| Priority | high | Resolution | fixed | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | RR16Q2.1 | |||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Merge Request Status | ||||||||
| Review Assigned To | marvintm | |||||||
| OBNetwork customer | No | |||||||
| Support ticket | ||||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0033119: Cashup does sequential scan of c_order table which takes very long with many orders. | |||||||
| Description | The OrderGroupingProcess.java which is part of the cashup has 2 queries which filter c_order by cashup id (orders related to cashup being currently processes). As the c_order table does not have an index for that cashup_id field this leads to 2 sequential scan's of the table which for high number or orders take very long. In test database with only 4.3M c_order each of the 2 queries takes roughly 3.2 seconds because of that. Adding index on that column reduces that time to a lot less (few hundred ms). Queries are: - OrderGroupingProcessorData.java:selectSplitOrderLines - insertHeaderNoGrouping Maybe also the grouping version of the 2nd | |||||||
| Steps To Reproduce | Found by following sequence: configure postgres db to log all queries i.e. slower than 1s Take database with big number of c_order configure to make invoice per order inside cashup. Make i.e. 87 tickets with 2 lines each Then process cashup. Check pg log | |||||||
| Proposed Solution | add index for cashup_id to c_order table | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||
|
||||||||
 Relationships |
|
Notes |
|
|
(0088196) migueldejuana (viewer) 2016-07-05 10:12 |
Repository: retail/backports/3.0RR16Q2.1/org.openbravo.retail.posterminal Changeset: 3c581207edd5792732aa61ee082c3103219d0ab5 Author: Stefan Hühner <stefan.huehner <at> openbravo.com> Date: Tue Jun 07 16:55:04 2016 +0200 URL: http://code.openbravo.com/retail/backports/3.0RR16Q2.1/org.openbravo.retail.posterminal/rev/3c581207edd5792732aa61ee082c3103219d0ab5 [^] [^] Fixed 33118: Add index on c_order.em_obpos_app_cashup_id to speed up Cashup That index will be used by at least 2 queries run in the cashup process which without it do 2 sequential scan of c_order table which is very slow with many orders. Used by: OrderGroupingProcessorData: - selectSplitOrderLines - insertHeaderNoGrouping --- M src-db/database/model/modifiedTables/C_ORDER.xml --- |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2016-06-02 18:11 | Orekaria | Type | defect => backport |
| 2016-06-02 18:11 | Orekaria | Target Version | RR16Q3 => RR16Q2 |
| 2016-06-03 15:03 | marvintm | Target Version | RR16Q2 => RR16Q2.1 |
| 2016-07-05 10:12 | migueldejuana | Note Added: 0088196 | |
| 2016-07-05 10:12 | migueldejuana | Status | scheduled => resolved |
| 2016-07-05 10:12 | migueldejuana | Resolution | open => fixed |
| 2016-07-05 18:45 | marvintm | Review Assigned To | => marvintm |
| 2016-07-05 18:45 | marvintm | Status | resolved => closed |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |