Re: Temp tables performance question

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Temp tables performance question
Date: 2000-07-13 21:13:00
Message-ID: 396E30DC.3241D9CD@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > I have a question about performance issues related to temporary tables.
> > IIRC temporary tables were implemented as ordinary tables with some
> > pre/post-processing to give them unique names so that they would not
> > clash with similar-named tables from other sessions.
>
> Right, there's basically no performance difference at all from ordinary
> tables.
>
> It'd be possible to have them go through the "local buffer manager"
> for their entire lives, rather than only for the transaction in which
> they are created, as happens for ordinary tables. This would avoid
> at least some shared-buffer-manipulation overhead. I'm not sure it'd
> buy a whole lot, but it probably wouldn't take much work to make it
> happen, either.

I was hoping that at least fsync()'s could be avoided on temp tables
even without -F.

Other kinds of improvemants should be possible too, due to the
essentially non-transactional nature of temp tables.

> I think it would be folly to try to make them use a different smgr or
> avoid WAL; that'd require propagating differences between ordinary and
> temp tables into way too many places.

Does using a different storage manager really need propagating
differences
in other places than the storage manager code ?

In an ideal world it should not be so ;)

-----------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-07-14 00:02:19 Re: Vacuum only with 20% old tuples
Previous Message Tom Lane 2000-07-13 16:17:48 Re: Questions relating to "modified while in use" messages