Re: [Gnumed-devel] patient search widget timings

[richard terry]

It's interesting that it is so slow just to return a straight list of fields 
like name, surname, dob etc. When I display my stuff the pop up box comes up 
with name, surname, street, suburb cause in general practice that's how we 
recognise which 'john brown' we need from the list. DOB I guess more 
applicable and should be included, is there something about that field which 
is causing problems?

Richard

On Friday 28 March 2003 11:30 am, you wrote:
> > > 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
> tomorrow.
>
> Karsten