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
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 |