On Tue, Jul 14, 2009 at 11:34 AM, <genegurevich@xxxxxxxxxxxx> wrote: > Thank you for the info. I found that hidden parameter for my own education. > I did some testing with higher MBRC (from 32 to 128), but that did > not change the timing. I also tried increasing arraysize to 5000, and that > led to increase in time by about 30%. I am running again with lower > value (500). I mentioned arraysize 200 for a specific reason. Not 2000, not 5000, not 10000. Increasing arraysize aids in throughput up until a certain point at which the performance curve inverts. More is not always better. I believe Tom's array flat pro*c program uses 100 for the array size, though it can be specified on the command line. I've found that 100 or 200 is generally the best place to be on the curve. > As far as the qref latch, what can I do to handle it? The Suck it dry > article says to increase the parallel_execution_message_size, but > this may create issues if the consumer is taking time to process the > incoming data, which is probably the case here. Is there anything > else I can do here? Generally these are idle PX waits, although I would recommend setting parallel_execution_message_size=16384 The default is pretty small in todays high memory hosts and this will become the new default in the next Oracle release. If the problem is the consumer slave set is slower than the producer slave set, and it is just that way, than there is little that can be done -- Regards, Greg Rahn http://structureddata.org -- //www.freelists.org/webpage/oracle-l