Fwd: [bdbxml] Space Time Complexity - Performance issues
Manish Rai Jain <[email protected]> Tue, 13 Sep 2005 11:09:13 +0800
| Newsgroups | gmane.comp.db.dbxml.general |
|---|---|
| Message-ID | <[email protected]> |
---------- Forwarded message ---------- From: Manish Rai Jain <[email protected]> Date: Sep 13, 2005 11:08 AM Subject: Re: [bdbxml] Space Time Complexity - Performance issues To: George Feinberg <[email protected]> Thanks George! This will surely help :). Just to clarify more, In general, a well-written query with a good index will take > time/space proportional to the number of results. > In a scenario where the query is something like this: where (some $someacc in $acc satisfies contains($someacc, "keyword")) or (some $sometax in $tax satisfies contains($sometax, "keyword")) or (some $someauthors in $authors satisfies contains($someauthors, "keyword")) or (some $somescop in $scop satisfies contains($somescop, "keyword")) or (some $somenam in $nam satisfies contains($somenam, "keyword")) If all the fields are properly indexed, in such a case, how will the performance fare? That is, will it be proportional to the result set; or it will depend upon some other factors etc. Regards Manish On 9/13/05, George Feinberg <[email protected]> wrote: > > > Manish, > > These are large, open-ended questions. It's possible > to provide information, but not precise numbers. > > > > Hi all > > I wanted to know what is the space time complexity (or performance > > limits) for > > 1. Querying across a container with n documents (Indexed) > > With the proper query and index, this may be resolved with > a single index lookup operation (btree lookup) and fetching > of the target document(s). > In general, a well-written query with a good index will take > time/space proportional to the number of results. > > Without a proper index and/or query, this could iterate through > the entire container, examining each document. > > > 2. Querying across a container with n documents (non-Indexed) > > Best-case, this is proportional to the number of documents. A nasty > query can be very slow. > > > 3. Cross-querying across 2 containers having m and n documents > > (Indexed) > > This is close to the same as (1) with good indexes, except there > will be 2 index lookups (one per container), not one. > > > I want to know the theoretical limits of these queries. Also, it wd > > be great if you can fwd me some experimentation values etc. or any > > other documents which provide info abt the theoretical limits of > > querying, indexing, and population. > > The limits, theoretical and not, vary widely with the queries involved. > Even with good indexes, it's possible to construct a query that exceeds > time/space available. > > Some hard limits in the current product: > o document IDs are 32-bit, so that limits number of documents in > a container. > o there are no hard limits on number of containers > o size of a container is limited by the file system's maximum > file size, > which is platform-specific. > > Regards, > > George > >