I did specify too little details at purpose. I'm more interrested in your approach. (method and measurement). client side caching was one thing I didn't think of. (and of course it raises the question how to measure it properly). Maybe you can spend some minutes and change your ' I would think' into a small testcase? On Thu, Mar 11, 2010 at 23:15, Wolfgang Breitling <centrex@xxxxxxxxxxxxx>wrote: > I think there are too many variable to allow for a proper "contest". For > example are you after a fastest single sql, i.e. 1 parse, 1 execute, 1 > fetch, or fastest multiple execution sql. In the latter case I would think a > client-side result cache for a sql which returns a constant from a constant > table ( e.g. dual ) should be fastest as only the first sql will make the > database roundtrip. All the other executes will get the results from the > client-side cache as long as that cache is not invalidated which it > shouldn't if the result is a constant from a table whose content doesn't > change. For a single exec sql result-caching obviously doesn't do anything. > > > Quoting Martin Berger : > > I just wanted to start this discussion, as I'm interrested in the bits and > pieces which affect performance. > I will not buy and hardware or install a particular SW-version, but I'm > interrested in the slightly differences, also all your ideas; and this > 'quest' might be challenging for some. > > > Am 11.03.2010 um 21:41 schrieb Storey, Robert (DCSO): > > Guess I’m missing something? > Are you asking whats the fastest query that can be written based on > building the fastest possible hardware base, oracle version, etc? > > > > > > > -- > Wolfgang Breitling > Centrex Consulting Corporation > -- Martin Berger martin.a.berger@xxxxxxxxx Lederergasse 27/2/14 +43 660 660 83306 1080 Wien http://berx.at/