Thank you for your comment – it has drawn my attention to the fact that 11g (possible 11.2) has added a new feature to the pq_distribute hint that was in (or, at least) was not documented for 10g. The “single distribution” option for dealing with data loading.

The posting is simply an example of the type of investigation and level of knowledge required to make a decision of the type indicated by the manuals, so the quick answer to your last question is: “yes”.

>switching to a “broadcast” distribution bypassed the need for any sort of buffering at all, and the I/O to the temporary tablespace disappeared completely

Documentation ( http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements006.htm#BABCJHAF Table 3-23 ) lays down few rules about which distribution method should be used in which case (basically on the basis of difference in size of two table being hash joined)

Your comments on that ? Did you mean the same thing by suggesting “to switch to broadcast distribution in some cases) ?

Regards,
Amardeep Sidhu

b) Memory used by PX slaves to pass data to other PX slaves – this comes from the SGA, and possibly the only way to modify it would be to change the parallel_execution_message_size (originally the default was ca. 2KB).

c) Memory used by a slave for the “PX Buffer” type of operation described in this note, and that comes out of a normal ‘pga workarea’ – with the usual limitations on how you can affect the amount of memory that can be used for workareas.

in this thread, on link

http://oracledoug.com/serendipity/index.php?/archives/774-Direct-Path-Reads.html

The trick with the “direct path reads” is that Oracle manages to dispatch N buffers for read requests (probably 4), which is a CPU and memory intensive strategy, then comes back to the first buffer – which in this case requires a very short wait to fill. Then Oracle uses the data, dispatches a new read and moves on to the second buffer. In the interim the second read has nearly completed, but requires a few more microseconds… if Doug’s hardware were just a little faster, we wouldn’t see any direct path read waits.

Jonathon since parallel processing uses direct path read. if my DOP is 3 and i have 3 producer processes procedusing data for consumer processes. Since PGA is being used for reading data, in which area of PGA data is being buffered and can we increase and decrease the size of that area.

That was a description of the sorting mechanism – with the side effect that the memory needed for sorting N items of data required an overhead of roughly (N * 3 * pointer size) bytes – where a pointer is 32 bytes in 4 bytes in 32-bit systems and 8 bytes in 64-bit systems.

I don’t know the algorithm that is used for the so-called “V2″ sort in 10.2, but it seems to need an overhead of just one pointer per item. Not only is it less memory intensive, the algorithm is also less CPU intensive.

I think I suggested in my book that it might be a variation of the heap sort algorithm, but I recall an informal comment from an Oracle employee it wasn’t.

In a conference you said that until 10.2.0.2 Oracle used binary insertion trees to maintain a map for merges. What are the differences in the mechanism for sorting in 10.2.0.3 , 10.2.0.4 (and 11g) ?

Regards.

maybe this could be done also to cope with a slow client, or the risk of the client being slow. That is, “partition 8″ (that buffers the result set) is dumped to the temp tablespace to enable the kernel to free all the RAM it allocated (that could be huge of course). The result set rows are then read “slowly” as the client asks “slowly” for then by issuing the FETCH db-calls (more in detail, as the virtual tables Q2 become empty thanks to the client reading).

I’m thinking to something similar to the mechanisms linked to the “sort_area_retained_size” parameter for serial sorts.

It couldn’t be that bad when the client is fast enough to consume the result-set as it is produced: when the hash join completes, the buffer is empty, hence there will be nothing to dump.