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 13:54:46
Message-ID: 73AC245CA75C0F4581D33517483544D504E75AF8@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: 05 June 2002 12:58
> To: Sam Liddicott
> Cc: pgsql-bugs(at)postgresql(dot)org
> Subject: RE: [BUGS] drop tempoary table VERY slow
>
> Interesting. Those are pretty long times to take for a
> vacuum on those
> tables - if you are using 7.2.x have you tried more frequent vacuum?
> Perhaps with a vacuum full each night?

Hmmm.

> I think that the aborting transaction approach, since it
> works, is most
> likely to be your best bet in general, however.
>
> It would be interesting to see the 'vacuum full analyze'
> results for the
> system tables in that DB, although perhaps less interesting while you
> are running your current solution - maybe a comparison would be
> worthwhile.

Alas we won't be able to downgrade as it affected the service seriously.
In doing a full vacuum I notice such errors as:

NOTICE: Index pg_index_indrelid_index NUMBER OF INDEX' TUPLES (92) IS NOT
THE SAME AS HEAP' (86). Recreate the index

Hmm. It's not my index (of course) I'm not sure how to go about re-creating
it.

Sam

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2002-06-05 17:57:29 Re: [Fwd: Bug#146689: postgresql-client: 'GRANT DELETE' autocompletion
Previous Message Andrew McMillan 2002-06-05 11:57:47 Re: drop tempoary table VERY slow