anchor.diff:  |===
   
   Take these changes adding excluded names to Correa pulchella J.B.Mackay ex Sweet which is this node
  -https://biodiversity.org.au/nsl/services/node/apni/5424450 at 2015-12-23 08:49:16.608000 +11:00 but was a different
  +https://id.biodiversity.org.au/node/apni/5424450 at 2015-12-23 08:49:16.608000 +11:00 but was a different
   node 3 minutes earlier. The reality is that these changes were meant to be done as a batch and should only have been
   published once.
   
  
positive.code: 
  == Placement Rules
  
  NOTE: there is a new more succinct document "placement-rules.adoc" which is based directly on the new implementation
  after we've tested and reviewed the results with users. Consider this document to be the before picture and that as the
  after.
  
  
negative.code: Two million record tree would be expected to take up around 285MB based on the estimated data usage figures quoted above
  for 35k names.
  
  doing a select on 4 819 443 tree_version_elements and ordering by name_path on my local machine took 250ms
  
   sql> select te.simple_name, te.name_link, tve.element_link tree_link, tve.name_path
        from tree_element te
                    join tree_version_element tve on te.id = tve.tree_element_id
   [2018-11-28 13:46:28] 2000 rows retrieved starting from 1 in 249 ms (execution: 144 ms, fetching: 105 ms)
  
  after optimising postgresql this came down to 1m 40s.
  
  With an index on name_path a search for everything under Eucalyptus on 4.8M tree_elements (159213 results 2000 fetched)
  takes ~200ms.
  
   sql> select te.simple_name, te.name_link, t.host_name|| tve.element_link tree_link, tve.name_path
        from tree_element te
                    join tree_version_element tve on te.id = tve.tree_element_id
                    join tree t on tve.tree_version_id = t.current_tree_version_id and t.accepted_tree
        where name_path like '%/Eucalyptus/%' order by name_path
   [2018-11-28 13:42:41] 1168 rows retrieved starting from 1 in 203 ms (execution: 137 ms, fetching: 66 ms)
  
  More machine grunt may improve performance. (After optimising postgresql this came down a lot)
  
  ****
  My local machine is an i7-4820K 3.70GHz CPU x 4, 32GB machine with a 500GB Samsung SSD. Postgresql had not been optimised
  