Re: perfomance question

[Vernon Hamberg <vhamberg@xxxxxxxxx>]

YMMV. Key word is "can" be slower. It depends. Views do not have the access
path maintained, they actually run the SQL select that is in their
definition, each time. In a long running job this may not be too important.
In a job where you want quick initial response, a join logical might be
more efficient.

CLRPFM is light years faster than delete from filename. It's too bad the
optimizer doesn't take advantage of this when it is given no where clause.

By its very lovely and handy generic nature, SQL will probably have a
longer code-path than native I/O. Because of this, we tend to go with
native I/O, to get the leanest, meanest implementation.

Again, the famous constant - It depends!

Regards

Vern

At 12:36 PM 10/14/02 -0500, you wrote:
> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> For performance avoid SQL?  We have a gent here who is no big fan of SQL.
> He ran some extensive checking, with blocking and all sorts of options. He
> found the performance of SQL better.  (It just wasn't better enough to get
> him to use it all the time.)
>
> Rob Berendt
>
> Vernon Hamberg <vhamberg@attbi.com>
>
> Heba
>
> For max performance, generally avoid SQL - too much overhead - and go for
> native record I/O. SQL is convenient for development but can be slower.
>
> Vern