Re: single task postgresql

Greg Copeland wrote:
>
> 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.

It cerainly wont give UNIX developers the warm and fuzzies, thats for sure, but
I have developed Windows software since there has been a Windows, and believe
me, there is no "non-trivial" Windows application which is not forced, at some
point, to do these sorts of things.

Windows, as a platform, is pure and simple, a disaster.

>
> >
> > 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.

Not nessisarily true. The system memory map should not have the same criteria
for disk writes. A memory mapped file has some notion hard disk "persistence."
NT will maintain the disk image. When a view of the system memory is mapped,
there is no requirement that the disk image is written. It will follow the OS
virtual memory strategy for generic memory. (It may even make it more
persistent than generic RAM, I will have to double check.)

>
> 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.

I am not sure if there will be much benefit, I too am skeptical, with one
caveat, if NT or Windows is using a shared file handle, there may be contention
at the disk level for the disk, and that could impact performance.

On NT, puting the shared memory file on one disk, and the database on another,
one should be able to see how often the disk which contains the shared image is
written.

Another posibility is to create a RAM disk and put the shared memory file on
it.

>
> 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.

Sigh, it looks like I have to reinstall NT and startup my Windows development
stuff again. I was having so much fun the last few years developing for Linux.
Again, sigh. :-|