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)
Список: pgsql-performance

Скрыть дерево обсуждения

performance of temporary vs. regular tables  (Joachim Worringen, )
 Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
  Re: performance of temporary vs. regular tables  (Joachim Worringen, )
   Re: performance of temporary vs. regular tables  (Thom Brown, )
    Re: performance of temporary vs. regular tables  (Joachim Worringen, )
     Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
      Re: performance of temporary vs. regular tables  (Joachim Worringen, )
   Re: performance of temporary vs. regular tables  (Andres Freund, )
    Re: performance of temporary vs. regular tables  (Joachim Worringen, )
     Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
     Re: performance of temporary vs. regular tables  (Joachim Worringen, )
      Re: performance of temporary vs. regular tables  (Rob Wultsch, )
      Re: performance of temporary vs. regular tables  ("Pierre C", )
       Re: performance of temporary vs. regular tables  (Joachim Worringen, )
        Re: performance of temporary vs. regular tables  ("Pierre C", )

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 по дате сообщения:

От: Merlin Moncure
Дата:
Сообщение: Re: Query timing increased from 3s to 55s when used as a function instead of select
От: "Jorge Montero"
Дата:
Сообщение: Re: Query timing increased from 3s to 55s when used as a function instead of select