Re: performance of temporary vs. regular tables

From: Joachim Worringen <joachim(dot)worringen(at)iathh(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: performance of temporary vs. regular tables
Date: 2010-05-25 09:52:20
Message-ID: 4BFB9DD4.5030702@iathh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Konrad Garus 2010-05-25 09:58:24 Re: shared_buffers advice
Previous Message Grzegorz Jaśkiewicz 2010-05-25 09:38:02 Re: performance of temporary vs. regular tables