Re: [Gnumed-devel] some 1st cut proposed optimizations to emrbrowser

[Karsten Hilbert]

On Sat, May 27, 2006 at 09:12:47PM +0800, Syan Tan wrote:

> on another list, I mentioned that I thought it doesn't matter whether the
> backend is a networked flat file system database
> like  DBase , or  a sophisticated column clustering , AI tree prune searching
> database like Postgres,
It matters not regarding access speed (which - at this level
of decision - shouldn't be a concern anyways) but it very
much matters regarding data integrity.

> I thought that when
> it came to retrieving very large medical records for user browsing and
> editing,  performance would be greatly affected
> by the access pattern of the client program.
Absolutely. That's why PostgreSQL does not even try to guess
on this and offers a host of options to tune to your actual
workload pattern. That's also what Oracle et al try to solve
by *observing* access patterns and trying to genetically
optimize themselves regarding indices, cached values,
materialized views etc.

> I proposed that  the ability
> separate retrieval of title/summary data vs .
> large blocks of text or binary data was one important consideration, and from
> the point of usability, an emr viewer
> should be opened quickly , without blocking waiting for large amounts of data
> to arrive from the server - non -blocking
> retrieval of the medical record.
I agree but only so much.

> Karsten argues that incomplete display of
> data may not be desirable.
Again, yes, but only so much. If one cannot display all the
data quickly enough one ought to display less *right away* :-)

> The changes are a compromise :-  the user only sees one encounter narrative 
> set
> at a time when using the emrBrowser, so why
> not retrieve each narrative set as it is browsed ?  However,  at some stage ,
> it might be useful for the client to have
> all the emr record cached client side,  e.g. for faster browser operation, so
> why not set off a separate thread which does
> the original bulk retrieval of the narratives,  and when it completes, load 
> the
> client side cache ,
That's exactly the approach we are after. One nitpick: the
next overhaul of the EMR browser will display the data for
all encounters for a given issue on the right hand side if
that issue is expanded. Showing just one narrative for the
selected encounter is not usable (and Richard will surely
say: told you so).

>   It 's just a bit of fun to make gnumed more sophisticated , but really, just
> having one encounter retrieval at a time
> for emr browsing is enough,
Let's make that "one episode".

> and this isn't multithreaded. 
Yes, I do think even unthreaded will go a long way if we
retrieve data upon expansion of branches. Now, even then
pre-fetching will speed things up no end.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346