Re: drop tempoary table VERY slow

From: "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com>
To: "Andrew McMillan" <andrew(at)catalyst(dot)net(dot)nz>, "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: drop tempoary table VERY slow
Date: 2002-06-05 09:02:53
Message-ID: 73AC245CA75C0F4581D33517483544D504E7594A@conwy.leeds.ananova.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> -----Original Message-----
> From: Andrew McMillan [mailto:andrew(at)catalyst(dot)net(dot)nz]
> Sent: 02 June 2002 11:52
> To: Sam Liddicott
> Cc: pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] drop tempoary table VERY slow
>
>
> On Fri, 2002-05-31 at 22:28, Sam Liddicott wrote:
> > And when I do drop a table CPU usage goes to 99% on one CPU.
>
> When did you last do a vacuum? If you are adding and
> dropping temporary
> tables a lot, perhaps you should vacuum pg_class and
> pg_attribute often
> as well.

I do a vacuum analyse every night on that whole DB, cron logs show pg_
tables are also vacummed, taking 97 seconds for pg_class and 463 seconds for
pg_attribute.

The DB size is about 10G and we do about 16,000 temporary tables per day.
The whole thing has become enourmously faster since we enclosed the queries
in an aborting transaction.
(If you are interested it serves Ananova TV listings at
http://www.ananova.com/tv_listings/_tv_full_listings.html)

Sam

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew McMillan 2002-06-05 11:57:47 Re: drop tempoary table VERY slow
Previous Message pgsql-bugs 2002-06-05 08:38:17 Bug #682: current_timestamp reporting time incorrectly