Re: extended stored proc programming
From: Bonj (Bonj_at_discussions.microsoft.com)
Date: 10/09/04
- Next message: Andrew J. Kelly: "Re: SQL SERVER Rollback Problems"
- Previous message: Dan Guzman: "Re: ASP / SQLServer connection"
- In reply to: Adam Machanic: "Re: extended stored proc programming"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 9 Oct 2004 07:45:02 -0700
> As I said, an extended stored proc is not going to help you here,
> performance wise. If you want performance, you're going to have to do this
> operation in bulk.
Yes - what I was hoping to do is have an extended stored procedure do the
bulk operation, I thought being as it's operating directly within SQL
server's own process space, there wouldn't be any cross-process marshalling
going on all the time between SQL and COM.
> Any row-by-row solution that requires marshalling of
> data across processes/components is going to slow you down. If this were 78
> rows instead of 78 million it might not be a problem... But even just
> invoking the xp_hello example extended procedure 78 million times would
> probably take quite a while (I'll leave that test to you :) )
That's exactly why I want an extended proc that will do all the 78m rows
from one invocation, called once, reads the rows in one fell swoop and spits
them out to a table, by doing "insert outputtable(....) exec xp_myproc"
Anyhow, I've written a test project to practice all the techniques I'll
need, and it was a lot easier than I imagined actually. I have used a static
library project to contain the managed code, and it seems to work. I'll do
speed testing on it, and if it's significantly faster then so be it, but at
least I'll be able to try it out.
Thanks
- Next message: Andrew J. Kelly: "Re: SQL SERVER Rollback Problems"
- Previous message: Dan Guzman: "Re: ASP / SQLServer connection"
- In reply to: Adam Machanic: "Re: extended stored proc programming"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
