Hello!

Theoretical question.

For example

1) 10 sessions, each in its own thread, each connected to the same
database and executes 10 updates on the same table, each update
affects 1 row.

2) 1 session in one thread executes 100 updates on the same table,
each update affects 1 row.

What is faster?

On 19.04.2007 15:14, Alexander Smirnov wrote:
> Theoretical question.
>
> For example
>
> 1) 10 sessions, each in its own thread, each connected to the same
> database and executes 10 updates on the same table, each update
> affects 1 row.

The same row or different rows?

> 2) 1 session in one thread executes 100 updates on the same table,
> each update affects 1 row.
>
> What is faster?

Practical answer: my Seat Leon.

Seriously: I don't know what others will tell you but I can imagine
situations where either is faster.

Regards

robert

On Apr 19, 9:36 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 19.04.2007 15:14, Alexander Smirnov wrote:
>
> > Theoretical question.
>
> > For example
>
> > 1) 10 sessions, each in its own thread, each connected to the same
> > database and executes 10 updates on the same table, each update
> > affects 1 row.
>
> The same row or different rows?
>
> > 2) 1 session in one thread executes 100 updates on the same table,
> > each update affects 1 row.
>
> > What is faster?
>
> Practical answer: my Seat Leon.
>
> Seriously: I don't know what others will tell you but I can imagine
> situations where either is faster.
>
> Regards
>
> robert

Define faster. Is faster based on just the clock time from the start
of the update process to the completion of the process or does it
include the total run time of all 10 sessions verse the one?

If my choice is to run one session and perform 100 updates followed by
one commit verse splitting the data into 10 units of work, starting a
session for each unit, having the session perform the work, commit,
and return a completion indication to the master process then I would
probably choose to use one session for simple updates since 100 is a
pretty small number. In this case the overhead would probably far
exceed the gain. Because there are a great many details and
performance issues to consider for each time you think you want to do
this I would rely on the Oracle PQO feature to determine if a task
should be ran parallel.

HTH -- Mark D Powell --

Based the on clock time from the start of the update to the
completeion of the process.

I want to know how much would simultaneous updates on the same table
but from the different sessions and on the different rows slow down
each other. Is it (in rough estimate) a linear function of the number
of these parallel updates?

On Thu, 19 Apr 2007 12:20:20 -0700, Alexander Smirnov wrote:

> Based the on clock time from the start of the update to the completeion
> of the process.

So, what stops you from trying?

--
http://www.mladen-gogala.com

Alexander Smirnov wrote:
> Based the on clock time from the start of the update to the
> completeion of the process.
>
> I want to know how much would simultaneous updates on the same table
> but from the different sessions and on the different rows slow down
> each other. Is it (in rough estimate) a linear function of the number
> of these parallel updates?

There is only one right answer: depends.

As Mladen recommends ... run benchmarks. You will get no where asking
for anecdotal advice that may be irrelevant to your application on
your hardware with your usage pattern.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org