Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

On May 3, 10:12 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:1178173985.960152.227740_at_l77g2000hsb.googlegroups.com...
> [snip]
>
> >> Eliminating self-joins is beneficial regardless of the implementation.
> > Beneficial to what ? Performance ? What performance ? Response
> > time ? concurrency ? cost of administration ? (Please answer these
> > precise questions). Do you realize that despite some lengthy (maybe
> > worthy) attempts at clarifying your point, some people here have no
> > clue what you are talking about.
>
> I'll try to be as concise as possible. Eliminating multiple self-joins
> reduces the number of passes through the data required to answer a query.
So you are taking about physical IO's. Right? Can you explain to me how you reduce physical IO's when itterating on the basis of number of lines multiplied by the number of operations required. Can you explain to me how

> This reduces (1) execution time,
How ? Could you establish that execution time is reduced in any concurrent environment.

(2) the duration that locks are held,
How ? What kind of lock ? What isolation level are you refering to ?

> (3) the amount of I/O required,
What IO's ? physical ? logical IO?

> (4) CPU utilization, and
Do you mean percentage of usage ?

> (5) the amount of
> memory required. The reduction in execution time improves response time.
I am not sure I understand I understand this last sentence. Are you aware that most of the time used in a process is mostly (compile + binding). Execution is a minor part of the resources used.

> The reduction in the duration that locks are held improves concurrency.
What locks ? How does the duration of a lock improve concurrency in most modern systems. Are your familiar with lock sharing ? Do you realize that most SQL DBMS do mutualize object physical accesses in a multi transactional context?

> The
> reduction in I/O required, CPU utilization, and memory required improves
> overall throughput. I would venture a guess that the cost of administration
> or at least of maintenance would be reduced as well: I personally think it's
> a lot easier to follow a simple fetch loop followed by a simple UPDATE FROM
> than a complicated set-based solution with four outer theta-joins, an outer
> equijoin, an inner equijoin, an aggregation and a union.
I still do not understand how having one view would be more cumbersome to maintain then several operations (update, creation of additional objects)...

Cursors are the cause of most timeouts I face daily. (whether due to dealock, excessive HD/RAM swapping or exlusive object locking).

Regards...
> [snip]
Received on Thu May 03 2007 - 11:33:32 CEST