Re: performance of temporary vs. regular tables
От | Joachim Worringen |
---|---|
Тема | Re: performance of temporary vs. regular tables |
Дата | |
Msg-id | 4BFB9DD4.5030702@iathh.de обсуждение исходный текст |
Ответ на | Re: performance of temporary vs. regular tables (Grzegorz Jaśkiewicz <gryzman@gmail.com>) |
Список | 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 по дате отправления: