gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Postgres query / display speed was Re: Release Candid


From: richard terry
Subject: Re: [Gnumed-devel] Postgres query / display speed was Re: Release Candidate 1.0.rc3
Date: Wed, 21 Sep 2011 12:16:08 +1000
User-agent: KMail/1.12.4 (Linux/2.6.31-23-generic-pae; KDE/4.3.5; i686; ; )

On Wednesday 21 September 2011 11:02:28 Jim Busser wrote:
> Under
> 
>       Medications plugin
>       Add / edit
>       Brands
> 
> the display of my 13,000 brands requires 30 seconds to build (debugging
>  mode) and 27 seconds (non-debugging). Vacuuming seemed to make little
>  difference (an imprecisely-timed 25 seconds).

This shouldn't be a problem in practice  Jim - I just ran my postres drug view 
(admittedly not your database), some 10,000 items in the complex multi-table 
view took about 6 seconds over the network.

 Doing an instring search on a single letter producing 8000 results * 60 fields 
each  took about 4 seconds, but doing an instring search on 3 letters like 
'%amo%' took <100msec, once you've typed eg amoxi takes <30msec.  And all that 
without anything more than a primary key, no other indexes on any of the table 
fields.

Hence presuming your search routines using a delay timer which only flicks off 
the query to the server once the user stops typing should be pretty much 
instananeous.

if you are not retrieving all the complex multi-joined fields or doing eg 
'amo%' as the search its much quicker.

I just checked and ive got 176,000 pathology results in my results table and 
pulling out  patients stuff is pretty much instantaneous.

Regards

richard
> 
> The above is despite having the db locally on same machine, a 6-month old
>  MacBook Pro. I am guessing that on a server it would take longer.
> 
> Maybe it is not a relevant test, because a user would not (normally) want
>  to display 13,000 results however with lab tests there could easily be
>  hundreds of results in a patient which needed to be displayed, maybe
>  thousands.
> 
> Is the speed (slowness) a reflection of (not) having an index that
>  corresponds to what the GUI is wanting?
> 
> Is it the nature of the join?
> 
> -- Jim
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel
> 



reply via email to

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