Re: RAM-only temporary tables

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: RAM-only temporary tables
Дата
Msg-id 20081106155310.GE5520@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: RAM-only temporary tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: RAM-only temporary tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: RAM-only temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Kevin Grittner wrote:

> Note that the 150 disk writes were for the CREATE and the DROP.  Does
> that mean that we'd actually shave 84 of 150 writes?

Hmm, you'd shave more than 42 but not 84, because index entries are not
deleted until a later vacuum.  (I'd say about 56 -- 42 plus the 14 heap
deletions).

> Also, if you're looking to account for all the writes, it's worth
> noting that my test declared a one-column primary key (on an integer
> column) in the CREATE TEMPORARY TABLE statement.

That probably makes up for the extra few writes that I didn't see in my
quick test.

> In suggesting this enhancement, my hope is that each session could
> check for a referenced table as a temporary in RAM before going to the
> system tables, in a manner vaguely similar to how space reserved by
> the temp_buffers GUC is used for temp table data.  I, of course, am
> suggesting this from a position of blissful ignorance of the actual
> complexity of making such a change.

Right -- I don't expect we can make use of such an idea readily.  Not
creating unnecessary pg_attribute entries for system columns is probably
a lot easier to do.  The idea of uncatalogued temp tables has been
suggested and rejected several times in the past.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: RAM-only temporary tables
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: plperl needs upgrade for Fedora 10