In D3DPOOL_DEFAULT, buffer contents are lost when fullscreen device loses focus and device is "lost" (D3DERR_DEVICENOTRESET or D3DERR_DEVICELOST). In this case, data within buffer is expected to be stored in video memory.

In D3DPOOL_MANAGED, a copy of data (that is stored within video memory) is stored in system memory, and as a result driver will restore it when device is lost.

D3DPOOL_SCRATCH is unsupported for vertex buffers.

D3DPOOL_SYSTEMMEM, will not guarantee better performance, because you'll be transferring data - frequently - from system memory to video memory in order to use this vertex buffer. For better performance on buffers that are frequently updated there are dynamic vertex buffers (see D3DUSAGE_DYNAMIC, D3DLOCK_DISACRD, D3DLOCK_NOOVERWRITE), which are located in D3DPOOL_DEFAULT. Also, Direct3D9 documentation says that resources created in system memory are normally not accessible for D3D9 device. For rendering from system memory there are DrawIndexedPrimitiveUP and DrawPrimitiveUP which are bound to cause problems on pure D3D9 device.

Also, there's absolutely no guarantee that either flag makes device work as you think. If common sense tells you it should work this way, but this is not documented in specification, according to Murphy's law, it probably doesn't work the way it should. For all practical purposes, driver implementation could be written by insane lunatic, as long as it conforms to Direct3D specification.

Another thing is that those functions are documented. DirectX SDK comes with several help files - *.chm that can be read on any windows system, .HxI/.HxS that integrate into visual studio, plus there's online help on MSDN, which includes explanation for D3DPOOL. If you're asking questions like this, you haven't done the homework and did not read documentation. So go ahead and read it. If Direct3D9 documentation is no longer included into latest SDK, then simply get older version of it (summer of 2004).