Re: performance of temporary vs. regular tables - Mailing list pgsql-performance

From Joachim Worringen
Subject Re: performance of temporary vs. regular tables
Date
Msg-id 4BFB9DD4.5030702@iathh.de
Whole thread Raw
In response to Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz <gryzman@gmail.com>)
List 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


pgsql-performance by date:

Previous
From: Tyler Hildebrandt
Date:
Subject: Query timing increased from 3s to 55s when used as a function instead of select
Next
From: "A. Kretschmer"
Date:
Subject: Re: Query timing increased from 3s to 55s when used as a function instead of select