Skip site navigation (1) Skip section navigation (2)

Re: PERFORMANCE IMPROVEMENT by mapping WAL FILES

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Janardhana Reddy <jana-reddy(at)mediaring(dot)com(dot)sg>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PERFORMANCE IMPROVEMENT by mapping WAL FILES
Date: 2001-09-26 14:54:37
Message-ID: 200109261454.f8QEsbO08192@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Hi all,
>           By   mapping  the WAL files by each backend  in to its address
> space  using "mmap"  system call , there  will be  big
>  improvements  in performance  from the following point of view:
>               1.   Each  backend directly writes in to the address
> space  which is  obtained by  maping  the WAL files.
>                       this  saves  the write system call at the  end of
> every transaction  which transfres  8k of
>                       data from user space to kernel.
>                2.   since every transaction does not modify all the 8k
> content of WAL page , so by issuing the
>                        fsync , the  kernel  only   transfers only the
> kernel pages which are modified , which is  4k for
>                         linux so fsync time  is saved by  twice.
> Any comments ?.

This is interesting.  We are concerned about using mmap() for all I/O
because we could eat up quite a bit of address space for big tables, but
WAL seems like an ideal use for mmap().

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-09-26 14:57:58
Subject: Re: iscacheable for date/time?
Previous:From: Justin CliftDate: 2001-09-26 14:34:07
Subject: Re: Converting from pgsql to sqlserver?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group