{5} Assigned, Active Tickets by Owner (Full Description) (5 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

a1149546

Ticket Summary Component Milestone Type Created
Description
#131 Use real disk usage instead of byte size throughout the web application GUI enhancement 02/21/07

We are now gathering disk space usage (number of occupied 512-byte blocks) along with the size of each file - see #59. This is a better/more precise metric for determining where disk space is used, which probably is Earth's main purpose at this time. Therefore, the GUI should use this value instead in all situations. (Maybe it should be configurable in earth-webapp.yml.)


bruno

Ticket Summary Component Milestone Type Created
Description
#70 Add support for Capistrano Misc enhancement 01/01/07

See http://manuals.rubyonrails.com/read/book/17


#139 Get SSL certificate for open.rsp.com.au Misc task 02/24/07

Either we should get a proper (not self-signed) SSL certificate for open.rsp.com.au or we should not force people to use https.

I think it makes things seem hokey...


#153 RSP: Setup development and staging servers Misc task 03/01/07

Setup a development server that runs continuously on the trunk version of the code with a GUI too. This way we can test development code on a large amount of data.

We should also have a staging server which we can use to test upgrades of our production installation.


julians

Ticket Summary Component Milestone Type Created
Description
#138 Radial and Treemap views when combined with filters have very long running queries GUI enhancement 02/23/07

Each level that's represented in a view from the Radial or Treemap, when filtered (in this example, I used "root" or "uid=0".

SELECT sum(size) AS sum_size FROM files  JOIN directories ON files.directory_id = directories.id WHERE (files.name LIKE '%' AND files.uid = 0) AND (directories.lft >= (SELECT lft FROM directories WHERE id=65313)  AND directories.lft <= (SELECT rgt FROM directories WHERE id=65313)  AND directories.server_id = 2)

The explain plan for each of these queries is:

-------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=76161.92..76161.93 rows=1 width=8)
   InitPlan
     ->  Index Scan using directory_info_pkey on directories  (cost=0.00..8.57 rows=1 width=4)
           Index Cond: (id = 64466)
     ->  Index Scan using directory_info_pkey on directories  (cost=0.00..8.57 rows=1 width=4)
           Index Cond: (id = 64466)
   ->  Hash Join  (cost=1198.69..76139.09 rows=2273 width=8)
         Hash Cond: (files.directory_id = directories.id)
         ->  Seq Scan on files  (cost=0.00..71275.43 rows=728449 width=12)
               Filter: (((name)::text ~~ '%'::text) AND (uid = 0))
         ->  Hash  (cost=1197.99..1197.99 rows=282 width=4)
               ->  Bitmap Heap Scan on directories  (cost=145.12..1197.99 rows=282 width=4)
                     Recheck Cond: ((lft >= $0) AND (lft <= $1))
                     Filter: (server_id = 2)
                     ->  Bitmap Index Scan on index_directories_on_lft  (cost=0.00..145.05 rows=452 width=0)
                           Index Cond: ((lft >= $0) AND (lft <= $1))
(16 rows)

and issuing an "explain analyze" takes around 5 seconds. Take into account that the whole database is stored in a RAM file system.

I think we need to look at optimising these queries (if we can).


Note: See TracReports for help on using and creating reports.