Re: row level vs page level locking is it more than marketing hype? was Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

Pablo Sanchez wrote:

> ... and of course you end up with crappier performance with
> the row at a time vs set based approach.

	Yeah, tell me about it (unless you're Jeff Wong, in
	which case shut the hell up for once!).

> I was doing a bench for a customer and they were doing some
> nightly processing... looking at their code, I saw that one
> section was taking 2.5 hours. I rewrote it and that same
> section took a couple of minutes.
>
> What was the magic? Converted their row at a time logic to
> set based logic.

	I have to put up with a 3rd party product on one of
	the servers I administer that manages the department
	employees. Its payroll processing takes over 7 hours
	now just to process 4000 employees. Guess what its
	doing? Yep, row at a time between a client and the
	server. They're trying to tell me that the network
	is too slow etc. etc. etc. Part of the problem is
	that its I/O bound on its updates (the payroll
	transaction table has 11 indexes on it!!! Can anyone
	say NORMALISATION?). I'm trying to get them to
	review their schema design and rewrite their code
	as a stored procedure that runs on the server. It
	should run in well under an hour. Of course this
	means that its no longer compatible with the other
	databases they support. But what the hell. The other
	strange thing it does is selects for update. Why?
	I don't know, it runs in single user mode. No real
	need to generate 60,000 redundant locks.

-am Received on Fri Nov 28 1997 - 00:00:00 CET