On Thu, Feb 21, 2013 at 10:29 AM, Carsten Ziegeler <[email protected]>wrote:
> 2013/2/21 Marcel Reutegger <[email protected]>: > > Hi, > > > > it means it will traverse the entire workspace to find nodes with > > a sling:vanityPath property. > > So this query we're using as well: > > SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL > > will already be slow as hell with a large repo, right? > IIUC, the performance would be improvable by defining an index on the sling:alias property (or sling:vanityPath property in the original case). I suspect that this is going to be a necessity regardless of what node type is used, at least for sling:vanityPath. At least in our commercial product, it's not uncommon to see tens or hundreds of thousands of nodes with the sling:VanityPath mixin (only a vast minority actually have the property set). If Oak is going to get the list of all nodes with that mixin type and then filter out based on property existence, that's better than iterating over EVERY node, but not as performant as it is in JR2. Back to the original question, it might be possible to get the timing information by using our existing vanity path related performance tests. As we've had lots of issues with performance and vanity paths, I'd really like to get some hard numbers before changing direction. I don't have any problems changing the semantics, even though it is non-backwards compatible. Regards, Justin > > Carsten > > > > > Regards > > Marcel > > > >> -----Original Message----- > >> From: Felix Meschberger [mailto:[email protected]] > >> Sent: Donnerstag, 21. Februar 2013 14:33 > >> To: [email protected] > >> Subject: Re: Vanity Path query > >> > >> Hi > >> > >> You mean "property exists" querying will be slow out of the box ? > >> > >> What does slow mean compared to Jackrabbit 2.x ? > >> > >> Regards > >> Felix > >> > >> Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: > >> > >> > one more thing to consider... > >> > > >> > while it probably won't have that much of an impact with Jackrabbit > 2.x > >> > the situation is different with Jackrabbit Oak. Oak currently comes > with > >> > default indexes for jcr:primaryType and jcr:mixinTypes. If you now > >> > turn your query into 'FROM nt:base' Oak won't be able to leverage > >> > those indexes and the query will be terribly inefficient. You will > have > >> > to add an index on sling:vanityPath to make if efficient again. > >> > > >> > regards > >> > marcel > >> > > >> >> -----Original Message----- > >> >> From: Marcel Reutegger [mailto:[email protected]] > >> >> Sent: Donnerstag, 21. Februar 2013 12:53 > >> >> To: [email protected] > >> >> Subject: RE: Vanity Path query > >> >> > >> >> Hi, > >> >> > >> >>> Does changing "FROM sling:VanityPath" to "FROM nt:base" have any > >> >>> noticeable impact on performance or cost of the query ? > >> >>> Ian > >> >> > >> >> probably not. it might even be a bit faster because the query does > >> >> not have to filter by node type. > >> >> > >> >> regards > >> >> marcel > >> > >> > >> -- > >> Felix Meschberger | Principal Scientist | Adobe > >> > >> > >> > >> > >> > >> > > > > > > -- > Carsten Ziegeler > [email protected] >
