Thanks, My feelings for postgresql are well known, it is a great piece of code. Final question, do you support AQL with your current design?
On Tue, Jan 26, 2016 at 10:40 AM, Jan-Marc Verlinden < [email protected]> wrote: > Hi Seref, > > We tested with lots of queries, not with large datasets (tens of > thousands) within the system itself. But given the nature of the "normal" > relational DB schema and queries, this should be no problem at all. It's > good old postgres..:-). > > Jan-Marc > > Op di 26 jan. 2016 om 10:53 schreef Seref Arikan < > [email protected]>: > >> 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 > > -- > > 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
