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-20 11:33:02
Message-ID: 73AC245CA75C0F4581D33517483544D50531C6BD@conwy.leeds.ananova.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Sorry for the delays on this that machine actually died recently and had to
be rebuit before I could do any more tests.

> > > 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.

Are you very interested in the comparison? I could fake a load of the
non-transactioned tempoary table queries if you are really interested.

I also noted we sometimes get a load of temporary tables left lying around
that look "global" and we have to drop by hand.

After rebuilding the machine I did a dump from the other machine and
inserted on the new machine (schema, data and all) and the new machine is
VERY slow at queries; taking 4 seconds at 100% cpu at times instead of
0.2-0.5 seconds or so.

Yet if I copy over the binary files when the DB's are stopped the new
machine is very fast at queries.
Could this be because the new machine started on 7.2.1 with a different
optimiser and so never generated query stats the the old box did while it
was still on 7.2 ?

Sam

Browse pgsql-bugs by date

  From Date Subject
Next Message Ingo Ciechowski 2002-06-20 15:28:31 WHERE <timestamp-val>=NULL malfunction in release 7.2
Previous Message cnliou 2002-06-20 05:18:10 Re: could not convert (0xf9db) BIG5 to UTF-8