[Top][All Lists]

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

Re: [Gnumed-devel] patient search widget timings

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] patient search widget timings
Date: Fri, 28 Mar 2003 01:30:53 +0100
User-agent: Mutt/

> > 1) find all the IDs matching the search term that I typed
> > 2) get 'id, lastnames, firstnames, dob' for all those IDs
> As a matter of interest are you just searching first on firstname, surname, 
> or do you include code to try and match DOB etc as well (I would think this 
> would slow things down??)
Well, that much depends on what you type in :-)

#12345 -> search for patient ID
1234567 -> search for DOB or patient ID
hil, ka -> search for last and first name
hil, ka, 1412431 -> search last/first name + DOB

and variations thereof. The query generator tries to be smart
about what you intended to say with your search term (the time
for that is proven to be neglectable on my 266 MHz notebook).

The gruesome details of the attempt at smartness are to be
found in gmPatientSelector.queries_default().

Generally speaking, searching for the matching IDs does not
take long at all even for 200+ matches. It's the time needed
until the query
 "give me lastnames, firstnames and DOBs for the
  following patient IDs"
returns that worries me. It'd be interesting to time the
actual query on the backend (Postgresql allows for this, I
think) vs. the time needed to transfer data from "end of
query" until "in my Python code". I'll try to do that

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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