Re: RAM-only temporary tables

Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> That would make the file creation and unlink just under half the load.
> 
> Worst possible case :-( ... means that we wouldn't get much improvement
> without addressing both aspects.
> 
> It strikes me however that this does put some urgency into the question
> of how much per-relation FSM is going to cost us.  For short-lived temp
> tables the FSM is never going to have any usefulness at all, but in the
> current HEAD code it'll double the create/unlink load.

Agreed.

> Heikki, would it be reasonable to fix things so that a nonexistent FSM
> fork is semantically the same as an empty one, and not create FSM until
> there's actually something to put in it?

Possibly, but I'd like to understand what exactly the problem is. I 
tried running this:

CREATE TEMPORARY TABLE footemp (id int4);
DROP TABLE footemp;

with pgbench -f, but can't see any meaningful difference between 8.3 and 
CVS HEAD. Both can do about 300 tpm, or 700-800 with fsync=off. There 
probably is a measurable difference there if you run longer tests, but 
doesn't seem like the extra file creation+unlink is worth worrying 
about. With the caveat that this is on reiserfs, on my laptop. Does 
someone see a difference on other filesystems?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com