Re: WITHOUT OIDS
От | Andrew Bartley |
---|---|
Тема | Re: WITHOUT OIDS |
Дата | |
Msg-id | 000e01c2dddf$a89667f0$3200a8c0@abartleypc обсуждение исходный текст |
Ответ на | create view (Ryan VanderBijl <rvbijl-pgsql@vanderbijlfamily.com>) |
Список | pgsql-general |
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 > >
В списке pgsql-general по дате отправления: