Re: Temp table question

Let's end this thread now. You've completely missed my point, and the use of irony I made.

I agree with everything you say about simple, scratch-pad data. That's exactly what a temporary table is. You seem to want to be able to share that scratch-pad data amongst Users. I merely pointed out that to be able to do so would introduce complexities (like locking) which are already present for managing normal tables.

You said that it would be easy to do if Oracle stored the scratch-pad data in the SGA. Well, I pointed out that all ordinary table data IS in the SGA, and yet that simple locational fact doesn't seem to have permitted Oracle to dispense with horrible complexities like locks and latches and LRU lists.

You said it would be easy for one User to relinquish the temporary table and for another User to gain it. I pointed out that Oracle handles such relinquishing and acquisition already, for ordinary tables, and the mechanism they had to invent to allow it to happen involved horrible complexities like locks and latches.

In sum, you think it would be easy to share temporary table data amongst sessions. I don't. I think you'd end up using the same sort of locking mechanisms that exist for non-temporary table data. You could probably be more cavalier in the way you used that mechanism, but a mechanism of some sort there would have to be.

And I suspect that the Oracle developers kind of thought like I do, and not the way that you do, and decided that if you want to share data amongst Users it should be stored in proper tables, where proper locking and latching can ensure concurrent but not conflicting access.

And the name's not Roger, BTW.

HJR "kyle hailey" <oraperf_at_yahoo.com> wrote in message news:cos1atcqrf5s0qc6tp1tv6qd0pj4rn0s3s_at_4ax.com...
> Roger,
>
>
> The "normal tables" have a heavy footprint which you know of course
> so I don't have to point out the details of read conisitency and
> recoverablity involved with redo logging and transaction management of
> rollback segments. There is no need for this overhead if the
> information is disposible and only one user is manipulating the data.
> As you said a earlier in this thread,
>
> >>One of their main benefits is that run like greased lightening
>
> This is at odds with your last reponse which suggests using "normal
> tables" instead of temporay tables.
>
> From you response, I get the impression that you missed my point. I'm
> addressing the functionality of creating information that is only
> changeable by one user and is disposible thus no need for the
> transactional complexity of involved in rollback segments or disk
> write obligation of generating redo. The idea is basically a scratch
> pad, the contents or access or ownership of which could be given to
> another session.
>
> The complexity involved in this functionality is much simpler that the
> with "normal tables".
>
> Best
> Kyle Hailey
>
>
>
>
Received on Sat Mar 03 2001 - 00:59:59 CST