Message-ID: <4BFB9DD4.5030702@iathh.de>
Date: Tue, 25 May 2010 11:52:20 +0200
From: Joachim Worringen <joachim.worringen@iathh.de>
Organization: IAT GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de;
	rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: performance of temporary vs. regular tables
References: <4BFB837C.6010005@iathh.de>	
	<AANLkTik4_exB6U3GlfLMNIgPSk0G3RVQ8fWBTzwekrke@mail.gmail.com>	
	<4BFB91A8.20805@iathh.de>	
	<AANLkTilBD97tBH3f3-RHvXcYy7t3yCt6-JxAtZ15mVkF@mail.gmail.com>	
	<4BFB991E.40407@iathh.de>
	<AANLkTilN0Qrf0NoHRhGW4VWuRyj1Gpfe5qpLzeNHNyBH@mail.gmail.com>
In-Reply-To: <AANLkTilN0Qrf0NoHRhGW4VWuRyj1Gpfe5qpLzeNHNyBH@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Am 25.05.2010 11:38, schrieb Grzegorz Jaśkiewicz:
> WAL does the same thing to DB journaling does to the FS.
> Plus allows you to roll back (PITR).
>
> As for the RAM, it will be in ram as long as OS decides to keep it in
> RAM cache, and/or its in the shared buffers memory.

Or until I commit the transaction? I have not completely disabled 
sync-to-disk in my setup, as there are of course situations where new 
data comes into the database that needs to be stored in a safe manner.

> Unless you have a lot of doubt about the two, I don't think it makes
> too much sens to setup ramdisk table space yourself. But try it, and
> see yourself.
> Make sure that you have logic in place, that would set it up, before
> postgresql starts up, in case you'll reboot, or something.

That's what I thought about when mentioning "increased setup 
complexity". Simply adding a keyword like "NONPERSISTENT" to the table 
creation statement would be preferred...

  Joachim