[Top][All Lists]
[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