|Subject||RE: [IB-Architect] Fw: Slow deletion on large tables|
|Author||Claudio Valderrama C.|
> -----Original Message-----Clarified and noted. Thanks.
> From: Ann Harrison [mailto:harrison@...]
> Sent: Jueves 1 de Junio de 2000 10:07
> Jim said, I hope, that we don't know of a performance problem with
> large numbers of duplicates for insert or select. We all know about
> the problem with garbage collection after an index value in a long
> duplicate chain is deleted or changed.
> What's the solution? Don't define the FK but perform theSeems you were well awakened when reading that. You understood the point
> >lookup in the BEFORE INSERT trigger with a select/exists construction?
> No, referential integrity is more reliable than triggers because it
> is not bound to transaction context.
that wasn't said explicitly. Actually, I've put a little article on my site
because I received several private inquiries... newbies didn't figure out
that transaction isolation affected triggers to check for referential
> > I won't continue piggybacking the kinobi.performance NG hereThanks you, too. Three weeks later, a posting from a not IB-used person
> > unless ISC
> >people want to continue here in parallel.
> No, I'll go back to the performance list.
suggested that IB was 120 times slower than Sybase. After some digging
thanks to Holger Klemt, the issue resulted to be... guess what? The ODBC