Thread: win32 port --asynchronous I/O and memory

win32 port --asynchronous I/O and memory

From
"Merlin Moncure"
Date:
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


Re: win32 port --asynchronous I/O and memory

From
Jan Wieck
Date:
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.                                  #
#================================================== JanWieck@Yahoo.com #