Re: [HACKERS] win32 port --asynchronous I/O and memory

2003-02-03 Thread Jan Wieck
Merlin Moncure wrote:
 
 Just a quick question... are you guys using the C runtime or the win32
 API to do things like file i/o and memory allocation.  If you are using
 the win32 api, are you using asynchronous I/O?  Generally, how much raw
 win32 code do you expect to write (assumption: as little as possible).
 
 As for memory, what's the general allocation scheme?  I have not looked
 at the source much, but I know postgres has a very good memory manager.
 There are a few different ways of going about it.  I wrote a database
 backend of sorts a while back and my experience was that you have to
 take certain precautions or you are in danger of thrashing the server,
 which in extreme cases is basically the same as crashing the system.
 Part of the danger is memory allocations for the database sometimes
 compete with the file system caching, causing massive performance
 degradations.  MSSQL avoids this because it is very tightly wound with
 the virtual allocation system.

PostgreSQL's memory context system is untouched and uses the standard C
libraries malloc()/free() as in Unix.

As a rule of thumb, we only touched things that needed to be touched
because of missing features or differences in the C libraries.


Jan

-- 
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



[HACKERS] win32 port --asynchronous I/O and memory

2003-01-31 Thread Merlin Moncure
Just a quick question... are you guys using the C runtime or the win32
API to do things like file i/o and memory allocation.  If you are using
the win32 api, are you using asynchronous I/O?  Generally, how much raw
win32 code do you expect to write (assumption: as little as possible).

As for memory, what's the general allocation scheme?  I have not looked
at the source much, but I know postgres has a very good memory manager.
There are a few different ways of going about it.  I wrote a database
backend of sorts a while back and my experience was that you have to
take certain precautions or you are in danger of thrashing the server,
which in extreme cases is basically the same as crashing the system.
Part of the danger is memory allocations for the database sometimes
compete with the file system caching, causing massive performance
degradations.  MSSQL avoids this because it is very tightly wound with
the virtual allocation system.

Merlin

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly