Re: RAM-only temporary tables

Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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