Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Temp table question

Re: Temp table question

From: kyle hailey <oraperf_at_yahoo.com>
Date: Mon, 05 Mar 2001 23:36:55 -0800
Message-ID: <pek2at0c4iut4snbp312e01p4c3tnkpvks@4ax.com>

Howard,

   Yes, I think it would be really cool to easily share scratch pad data in a light weight manner. You have even recently posted a senario yourself where you suggest that such functionality would have answered the posters question showing a possible use.

    The usefulness of functionality to customers is one of the big driving factors at Oracle developement. Oracle is extremely market driven. Market needs are propagated to developement in a number of channels, one of which is feed back directly from customers. Therefor I think it is interesting to discuss the needs and uses for a functionality in a forum such as this.

    There are already ways to share data in a non-transaction, non-logging way pipes and AQ and C callouts but this seems clumsy and introduces possible other inefficiencies. Its a definite possibility that I will set up my own shared memory with PLSQL call outs in C to manage it here - no recovery and no transaction management.  

   These are the kinds of issues we worked on in the performance group in kernel development in the emerald city ;)

   Latches/locks and memory allocation/management are relatively cheap and standard everyday programing techniques that are all you need for sharing data in a simple way. Recovery and transactional mechanisms such as row level locking and read consistency used by normal tables are easily an order of magnitude more expensive and the algorithms are complex and not in the general programming repetoire. These complicated and expensive techniques are avoidable for scatch pad data. There is no need for recovery of scratch pad data that is loosable at outage time, and there is no need for transactional concurrent access ie no read consitency or row level locking, for data that is all or nothing.

   If you are interested in a more in depth understanding of Oracle's management of transaction consistency, to get and understanding of the expense and even more so the complexity, you can look internal at Oracle for a presentation by Jean Yves Caleca called "Transaction Management Internals". The next best thing is the source code that's a pretty big investment. The presentations 120 pages took me a couple of days to translate from French into English for Oracle US people, now to fully understand them ...

   I see you are leaving the big O as well. I'm sure your impressively prodigeous and exacting answers will be well missed on this forum. I always enjoyed being able to count on a certain level of rigor from your responses.

Best
Kyle Hailey Received on Tue Mar 06 2001 - 01:36:55 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US