Re: single task postgresql - Mailing list pgsql-hackers

Sorry for taking so long to get back to everyone.  I wanted to post a
follow up to the profiling data that has been submitted as well as
comment on the provided link (thank you btw).

The profiling data provided had some minor issues with it.  It seems
that everything was able to run in exactly zero % of overall time.
While this doesn't have to mean the results are invalid, it does raise
that question.  It is certainly possible that the overall % duration for
the reported functions was so negligible that it should show up as 0%,
however, somewhere in the back of my head I seem to recall that cygwin's
profiler is broken in this regard.  So, while there are some minor
differences, there are no timings to indicate which path in which
profiling is consuming the greatest amount of time.  Is it possible to
run a longer benchmark to see if we can get anything to register with a
percent value higher than 0%?

At any rate, I'm still wading through the two files to determine if
there is yet any value to found within the profiling results.

Greg


On Wed, 2002-03-06 at 09:36, Oleg Bartunov wrote:
> Mark,
>
> I've found
> "Fast synchronized access to shared memory for Windows and for i86 Unix-es"
> http://www.ispras.ru/~knizhnik/shmem/Readme.htm
> Would't be useful ?
>
>
>     Regards,
>
>         Oleg
>
>
> On Wed, 27 Feb 2002, mlw wrote:
>
> > Oleg Bartunov wrote:
> > >
> > > On Wed, 27 Feb 2002, 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.
> > > >
> > > > 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.
> > > >
> > >
> > > Mark,
> > >
> > > do you consider to work on this issue ?
> >
> > Yea, let me think about it. What is your time frame? When I offered to work on
> > it, I thought it could be a leasurely thing. I have to get a machine running
> > some form of Windows on which to develop and test.
> >
> > I want to say yes, and if no one else does it, I will, but I'm not sure what
> > your timeframe is. If it is the mystical 7.3, then sure I can do it easily. If
> > you need something quickly, I can help, but I don't think I could shoulder the
> > whole thing.
> >
> > I have a couple things I have promised people. Let me get those done. I will
> > try to write an equivilent set of functions for shget, shmat, etc. as soon as I
> > can. Anyone wanting to run with them can hack and test PostgreSQL on Windows.
> >
> > How does that sound?
> >
>
>     Regards,
>         Oleg
>