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: | Whole Thread | Raw Message | 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
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 |