Re: fastest SQL?

  • From: Martin Berger <martin.a.berger@xxxxxxxxx>
  • To: Wolfgang Breitling <centrex@xxxxxxxxxxxxx>
  • Date: Fri, 12 Mar 2010 08:57:32 +0100

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/

Other related posts: