Remy
>First of all, thanks for the detailed report :)
No probs :)
>Really ? I thought query on the children and permissions tables (among
>others) would get a big boost if they were indexed.
Sorry if that wasn't clear - I meant "indices alone" with a revamped schema
yes I'd use indices all over.
>Ok. The thing is, I have no idea which particular db schema would yield the
>best performance. This probably also depends on the db used.
I have a few ideas and yes it might vary but not by too much I'd say.
>The current implementation of a JDBC store is meant to be mostly a
>"reference implementation", used as an example to develop new stores. I
>expect the performance of JDBC stores tweaked for a particular database to
>be a lot better.
>
>Basically, I would suggest leaving the JDBC store as is, and work in any
>optimised store in another package.
Oh yes, I agree - we need a simple reference one. The thing that led me to
post was that
in addition to creating a new store the way I suggested, we need to modify
the higher layers to pass down the depth of a search. (see later)
>The child store (here the JDBC store) is free to ovverride the default
>caching when it makes sense. Here, I think it would be an excellent idea to
>do that, since hopefully it would reduce the number of queries needed.
Yea, that's what I meant by "extend" - forgive me if I'm not yet up with
java terminology :) I meant "extend" as in "extend a class". Sounds like
"override" is the right term. :) Another one for the C -> Java
mind-conversion notebook.
>The SlideToken could hold a recommended caching policy field which would be
>set by the client. The store could use it to fill out its cache in a more
>intelligent fashion, knowing what's coming next.
Love it. I'll give it a go.
>Yes, this makes a lot of sense.
OK then I have a new project :) Seemed sensible to me but I just wanted to
run it by you.
Peter
