Re: RAM-only temporary tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: RAM-only temporary tables
Date
Msg-id 20081106155310.GE5520@alvh.no-ip.org
Whole thread Raw
In response to Re: RAM-only temporary tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: RAM-only temporary tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: RAM-only temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: RAM-only temporary tables
Next
From: Alvaro Herrera
Date:
Subject: Re: plperl needs upgrade for Fedora 10