Re: single task postgresql
От | Greg Copeland |
---|---|
Тема | Re: single task postgresql |
Дата | |
Msg-id | 1015441613.20269.184.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | single task postgresql (Oleg Bartunov <oleg@sai.msu.su>) |
Список | 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 по дате отправления: