Hi Jan-Marc, To clarify: when you say huge: do you mean that the result set is huge, or the the amount of existing data is huge? Are you able to comment on how query performance changes/stays the same when the result set size begins to grow?
On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden < [email protected]> wrote: > I believe your paper is about performance of an openEHR based system with > a relational database. It does not argues if this is the right approach. > And specifically on the performance we could not agree more...:-). > > In the past year we worked on three different versions, all completely > openEHR compliant. We compared them, so I believe we are entitled to > discuss. Let's see: > > 1. Our first version was Java based with a postgres DB, everything > stored as path/values. > Every query would take about a second. We did not even try complex > queries..:-). Also the GUI side did not know what to do with the > pathvalues. > 2. Second version was completely XML based, lots of Java with an Exist > DB. This version can be found in GitHub. > Results: a single query over 900 records took 100ms. But the scary > part was that performance exploded linear, so 90000 would take about 10 > seconds, even for the most simple (already indexed and optimized) query. > 3. Our current stack converts archetypes to an Object model and > persists this model to postgres. Indeed this needs some fancy tricks > (@Thomas), but it's doable...:-). > Performance is comparable with the findings in the paper, even with > huge queries. Performance is steady at about 1 to 3ms per query. No > optimization done yet, is not yet needed but could/will make it even > faster. > > Cheers, Jan-Marc > > Op di 26 jan. 2016 om 09:55 schreef 吕旭东 <[email protected]>: > >> Dear all, >> >> I just found there are lots of comments on our recent paper. Thanks for >> all these comments, I will read them and reply later. >> >> @Shinji, Of course the slides could be shared. >> >> Regards >> Xudong >> >> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI <[email protected]>: >> >>> Hi Ian and all, >>> >>> We, openEHR Japan had an unconference with Dr Lu and he gave us a >>> presentation for us about this research. >>> I will ask him if the slides would be shareble. >>> >>> Shinji KOBAYASHI >>> >>> 2016-01-25 22:04 GMT+09:00 Ian McNicoll <[email protected]>: >>> >>>> Interesting paper from China >>>> >>>> >>>> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0 >>>> >>>> Ian >>>> >>>> Dr Ian McNicoll >>>> mobile +44 (0)775 209 7859 >>>> office +44 (0)1536 414994 >>>> skype: ianmcnicoll >>>> email: [email protected] >>>> twitter: @ianmcnicoll >>>> >>>> Co-Chair, openEHR Foundation [email protected] >>>> Director, freshEHR Clinical Informatics Ltd. >>>> Director, HANDIHealth CIC >>>> Hon. Senior Research Associate, CHIME, UCL >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > -- > > Jan-Marc Verlinden > MedVision (mobile) > > *MedVision BV* > Aagje Dekenkade 71 > 2251 ZV, Voorschoten > www.medvision360.com > > This e-mail message is intended exclusively for the addressee(s). Please > inform us immediately if you are not the addressee. > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
