Bug 113673

Summary: Versions.getTxns is slow on a moderately loaded database
Product: [Retired] Red Hat Web Application Framework Reporter: Daniel Berrangé <berrange>
Component: otherAssignee: Vadim Nasardinov <vnasardinov>
Status: CLOSED DUPLICATE QA Contact: Jon Orris <jorris>
Severity: medium Docs Contact:
Priority: medium    
Version: nightly   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:00:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 106481    
Attachments:
Description Flags
Explain plans for two queries none

Description Daniel Berrangé 2004-01-16 12:22:28 UTC
Description of problem:

The getTxns method generates a query that looks like


select vt.id as c_1,
       vt.modifying_ip as c_2,
       vt.timestamp as c_3
  from vcx_txns vt
       left join vcx_obj_changes voc on voc.txn_id = vt.id
       left join vcx_obj_changes changes__voc on changes__voc.id = voc.id
 where (changes__voc.obj_id = 19628)
 order by vt.id desc;

This takes 100ms to execute on my current server populated with 4000
items.

Re-formatting it as

  select vt.id, 
         vt.modifying_ip, 
         vt.timestamp 
    from vcx_txns vt, 
         vcx_obj_changes voc, 
         vcx_obj_changes changes__voc 
   where voc.txn_id = vt.id 
     and changes__voc.id = voc.id
     and changes__voc.obj_id = 19628 

Reduces it to 7ms

This is on PG 7.3.2 / RHEL 2.1. Attaching explain plans and other
interesting info.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Daniel Berrangé 2004-01-16 12:24:55 UTC
Created attachment 97052 [details]
Explain plans for two queries

Comment 2 Daniel Berrangé 2004-01-20 12:22:10 UTC
I was smoking something when I posted this. The two queries I
mentioned aren't functionally equivalent - one is an outer jouin the
other not.
This is also a duplicate of bug 113480 since getCreationTxn and
getLastTxn just delgate to this method.


*** This bug has been marked as a duplicate of 113480 ***

Comment 3 Red Hat Bugzilla 2006-02-21 19:00:47 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.