Create memory workpads by using the SPUPad

This section describes the SPUPad feature, which allows UDX developers to allocate a named, unique, area of memory as a temporary storage area and workpad.

A SPUPad is typically stored in memory on the S-Blades, but it can also be in memory on the host. Its location depends on the location of the user tables on which it operates. When a SPUPad runs on an S-Blade, the system creates one SPUPad for each dataslice that is managed by the S-Blade.

A user-defined function or user-defined aggregate can call the SPUPad routines to create a SPUPad, write data to it, and read data from it. The SPUPad is temporary because it persists only for the lifetime of the transaction or transaction block that called the function that created it. When the transaction completes, the memory that is used for the SPUPad is automatically freed.

The SPUPad feature allows UDX developers to allocate and write data directly to the memory of the S-Blade or the Netezza Performance Server host. Use caution when you are using this feature. You should be familiar with the Netezza Performance Server architecture and verify your code and memory allocations, as problems in the code can create out-of-memory situations, S-Blade resets, and other effects that would affect the performance and availability of your Netezza Performance Server system.