Tom Lane wrote:
"Kevin Grittner" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
