Re: single task postgresql

mlw wrote:
> Greg Copeland wrote:
>
>>Windows does not really have shared memory support. This has been a
>>beef with the Win32 API for a long time now. Because it has been a long
>>time complaint, it was finally added in Win2000 and later. Likewise,
>>I'd like to point out that thinks like sims, shared memory, pipes, etc,
>>and other entities commonly used for concurrent programming strategies
>>are slower in XP. So, because shared memory really isn't well
>>supported, they elected to have what is, in essense, memory mapped
>>files. Multiple processes then map the same file and read/write to it
>>as needed, more or less as you would shared memory. Unless you plan on
>>only targetting on Win 2000 and XP, it sounds like a waste of time.
>>
>
> This is not really true. Under DOS windows, i.e. 95,98, etc. Shared memory can
> be done in 16 bit land with a touch of assembly and a DLL. Allocate, with
> globalalloc, a shared memory segment. The base selector is a valid 32 bit
> selector, and the memory is mapped in the above 2G space shared and mapped to
> all 32bit processes.

That's fine ad all, however, we're talking about the Win32 API. None of
that qualifies. If you wish to implement back door magic for your own
use, I guess that's fine but I'd wonder how well it would be received by
the rest of the developers at large. I'm betting it wouldn't give me
the warm fuzzies.

>
> Under NT through 2K, yes using a memory mapped files is the way to do it, but
> you do not actually need to create a file, you can use (HANDLE)0xFFFFFFFF,
> which is the NT equivilent of the system memory file. The handle returned is a
> system global object which can be shared across processes.
>

Yes, that's fine, however, this pretty much puts us back to a memory
mapped file/shared memory implementation.

I guess you could have a feature set which is perhaps optimial (again,
I've not seen anything which indicates you'll see perf improvement) for
Win2000/XP platforms. Perhaps you'd be willing to perform some
benchmarks and provide source of random read/writes to these segments
and present to us for comparsion? I'm personally very curious as to see
if there is any addition speed to be gleaned even if I am doubtful.

On a side note, if you did create such a benchmark, I'm fairly sure
there are a couple of guys at IBM that may find them of interest and
might be willing to contrast these results with other platforms (various
win32 and unix/linux) and publish the results.

After all, if this path truely provides an optimized solution I'm sure
many Win32 coders would like to hear about it.

Greg