Re: single task postgresql - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: single task postgresql
Date
Msg-id 1015441613.20269.184.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to single task postgresql  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Hehe.

Thank, I just submitted another email about this very issue.

Greg


On Wed, 2002-03-06 at 12:55, Oleg Bartunov wrote:
> On 6 Mar 2002, Greg Copeland wrote:
>
> > 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%?
>
> timings doesnt' correct !
> gettimeofday doesn't works properly under Cygwin. It's claimed that
> 1.3.10 (we have used 1.3.9)
> "- Use QueryPerformance* functions for gettimeofday calls. (cgf)".
> We'll rerun tests and submit results.
>
> btw, Konstatntin Knizhnik  suggested that poor performance of postgres
> under cygwin+cygipc could be caused by locking. We need to look at
> task manager to see how cpu is occupied by postgres.
> >
> > 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
> > >
> >
> >
>
>     Regards,
>         Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>


pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: single task postgresql
Next
From: Bruce Momjian
Date:
Subject: Re: Postgresql backend to perform vacuum automatically