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 < half a second for > 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 [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
