|Subject:||Re: [Gnumed-devel] back from China|
|Date:||Tue, 18 Apr 2006 06:51:38 +0800|
it's in here , search for the word, cmd_alt .
If Carlos is back, maybe he can revise the sql . Would the performance improve
if the sql access was something like
get all the demographics linked to an id.
get all the health issues linked to an id
get all the encounters linked to an id.
get all the episodes whose health issues are linked to an id
get all the individual types of clin root items whose episodes whose health issues are
linked to an id.
It might improve, but if the record was very large ( say occupied more than
512 MB , or more than system memory, which seems unlikely ) ,
it might slow down tree building due to page swapping.
Also , even though the tree browser caches all the data in client virtual memory after sql selecting,
it still takes maybe upto 3 to 4 seconds to repaint/rebuild the entire tree for a large emr record,
so that suggests that applying reconstruction may have to be more thrifty , because python
, and maybe no language, is fast enough to rebuild the tree in a timely ( < 0.5 seconds) every time the notebook page is flipped away and back again.
Maybe I should try to con a pathology friend to contribute, he used to program the
commodore 64 when he was a teenager , and make platform games , a lot better than
my crummy missile command when I was 26 ; )
On Mon Apr 17 17:14 , Karsten Hilbert sent:
with replenished energy.
Syan, can you please resend the large UNION query to me
which sped up the EMR journal query so much ? I will set up
a view for you to use.
Richard, if you want we can pick up working again where
we left off.
Carlos, welcome back.
Greetings to everyone else. Please get in touch if you want
to work on something in particular.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Gnumed-devel mailing list
Description: Binary data
|[Prev in Thread]||Current Thread||[Next in Thread]|