gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: [Gnumed-devel] revisited tweak for v_emr_journal


From: Syan Tan
Subject: Fwd: Re: [Gnumed-devel] revisited tweak for v_emr_journal
Date: Mon, 25 Sep 2006 20:57:06 +0800



----- Original Message ----- 
From: Syan Tan <address@hidden>
To: Karsten Hilbert <address@hidden>
Sent: Mon Sep 25 20:56
Subject: Fwd: Re: [Gnumed-devel] revisited tweak for v_emr_journal


I substituted "v_pat_items vpi" with "v_pat_episodes vpi" ,
and with clin.clin_narrative join v_pat_items , I used clin.v_pat_narr3 
or clin.v_narrative_soap ;

my installation was also slow because blobs.med_doc was missing id_patient 
index.
and creating this index fixed a slow documents browser tab.

Some usability wishes :-  embedded mime applications within gnumed, 
addresses displayed on patient searches, patient search displays 
surname/firstname
in alphabetical order;
? dates of encounters following episode titles in emr browser. 

BTW, I have tried to bootstrap gnumed on a windows machine at work,
and am having a hard time getting python from the bootstrap directory 
to see where the link to client directory,
Gnumed package, is. 

Any suggestions  ?  

Getting pyPgSQL package on a windows installation of windows to work also was
a problem, I think I had to copy all the DLL files from postgresql into the
pyPgSQL site-packages directory.

This python path finding problem is almost as diabolical as java paths , would
put most end users off , I think.

  

On Mon Sep 25 13:10 , Karsten Hilbert address@hidden> sent:

>On Mon, Sep 25, 2006 at 09:06:01AM +1000, syan tan wrote:
>
>> there is actually no need to make gnumed asynchronous ; 
>Good to know !
>
>> what is required if optimization is wanted is to tweak the views so that 
>> sequential scanning on tables with tens of thousands of rows is not done.
>Yes.
>
>> Then emr journal ( as well as emr browser) will work in 
>> even the largest history in my test data. ( 6 years, almost weekly).
>That's pretty amazing.
>
>> One of the common join conditions is on clin_root_item.pk_item =  T.pk_item
>> where T is a table or view , but examination shows that the views only
>> want tables from v_pat_episodes, which has been optimized in the previous
>> post . 
>> 
>> manually, this came up with v_emr_journal,  v_hx_family,  v_lab_requests, 
>> and I think that was all. 
>Assuming I added the IS NULL index on v_pat_episodes is
>there anything else I need to do to the views you mention
>here ? Or is it just the list that needs to be re-created
>when dropping v_pat_episodes ?
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel









reply via email to

[Prev in Thread] Current Thread [Next in Thread]