By: vivekanand

vivekanand — Wed, 05 Oct 2016 08:15:01 +0000

very helpful, thankyou

By: Yuvi

Yuvi — Tue, 02 Aug 2016 10:46:06 +0000

Thanks for the nice post. 🙂 Quite helpful

By: Larry Smith

Larry Smith — Tue, 11 Jun 2013 17:31:41 +0000

I don’t know how much the following applies to SQL Server, but let me try anyway.
Early mainframes either didn’t have much in the way of interrupts, or else the operating system didn’t adequately support what there was of them. This hampered the performance regarding unit record (printers and punched card readers) peripherals. Printing was essentially a synchronous operation, with the CPU idle during operations to the (slow) printers (with similar comments for card readers).
One solution was to write print data to (relatively high-speed) magnetic tape, then later transfer the tape to a different (small) computer, whose main job was to print the contents of the tape, offline from the main computer. Cumbersome? Sure. But is was the best that could be done at the time.
Later, as hardware and software evolved, a new approach was used. Instead of a program printing directly to a printer (or even a tape), the data would be written to disk, and a separate background program would transcribe it to the printer(s). This process was called Simultaneous Peripheral Operations, On Line. Or SPOOL.
I suppose today we might call it an instance of the Producer-Consumer pattern.
So perhaps SQL Server’s use of the term spooling has nothing to do with sewing, but is analogous to the old intermediate-disk-file approach to printing.
See http://en.wikipedia.org/wiki/Spooling

Comments on: Spooling in SQL execution plans

By: vivekanand

By: Yuvi

By: Larry Smith