Re: WITHOUT OIDS

Thanks Steve,

A regular vacuum of the pg_attribute and pg_class tables still takes too
long.

Regarding the Idea of using scratch tables, I have also tried. It seems that
if I use temp tables in the process it runs a lot faster... why, I'm not
sure.  I have also found that using truncate slows down during the day and
It also presents it's own problems with rolling back changes.

Do you know what the down side is of using WITHOUT OIDS? And will it help
the problem of growing pg tables?



----- Original Message -----
From: "Steve Crawford" <scrawford@pinpointresearch.com>
To: "Andrew Bartley" <abartley@evolvosystems.com>;
<pgsql-general@postgresql.org>
Sent: Thursday, February 27, 2003 7:01 AM
Subject: Re: [GENERAL] WITHOUT OIDS


> On Tuesday 25 February 2003 4:59 pm, Andrew Bartley wrote:
>
> > The Function slows down during the day considerably.  I suspect it is
due
> > the constant creation and dropping of temp tables.  If I vacuum full
> > pg_attribute and pg_class it fixes the problem.  But unfortunately
> > vacuuming these table every run is not practical as it takes so much
time.
>
> Try regular vacuum - that should mark unused space in those tables as
> reusable so the table size should stabilize instead of growing.
>
> > create temp table test  as select * from test2
>
> If you are always creating the same tables then could you might (if there
> aren't locking issues) be able to set up empty copies of the tables and do
> something like:
>
> truncate table scratch_test;
> insert into scratch_test select * from test2;
>
> But the bigger question is what is it that you do that is creating all
these
> temp tables so often? Perhaps there is a completely different better
> alternative.
>
> Cheers,
> Steve
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>