From: | "Anton Melser" <melser(dot)anton(at)gmail(dot)com> |
---|---|
To: | "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg temp tables |
Date: | 2007-03-06 07:39:13 |
Message-ID: | 92d3a4950703052339o559a1455gd6e5dd3a23817cf2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 06/03/07, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> wrote:
> On Saturday 03 March 2007 10:33, Anton Melser wrote:
> > Hi,
> > I have been going around telling everyone that there is no point using
> > physical tables in postgres for temporary storage within a procedure.
> > Why bother bothering the system with something which is only used in
> > one procedure I said to myself... I have just learnt that with MS Sql
> > Server, this is not the case, and that there are locks on some system
> > table and temp tables eat up memory and lots of other unfortunate
> > things. Can someone give me a 101 on temp table considerations? Or
> > rather give me "the good link"?
>
> The main issue against using temp tables involve bloat of some of the system
> catalogs, but it's no worse than doing create/drop cycles with standard
> tables, and better because they don't suffer as much i/o load.
Thanks for your reply. I am managing a db that has some export scripts
that don't do a drop/create, but rather a delete from at the start of
the proc (6 or 7 tables used for this, and only this). Now given that
there is no vacuuming at all going on - this is clearly suboptimal but
in the general case is this better/worse than using temporary tables?
Thanks again,
Anton
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-06 07:46:30 | Re: pg temp tables |
Previous Message | Webb Sprague | 2007-03-06 07:03:54 | Re: Database slowness -- my design, hardware, or both? |