Re: drop tempoary table VERY slow - Mailing list pgsql-bugs

From Sam Liddicott
Subject Re: drop tempoary table VERY slow
Date
Msg-id 73AC245CA75C0F4581D33517483544D50531C6BD@conwy.leeds.ananova.internal
Whole thread Raw
In response to drop tempoary table VERY slow  ("Sam Liddicott" <sam.liddicott@ananova.com>)
List 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] pg_dumpall should permit quiet operation
Next
From: Ingo Ciechowski
Date:
Subject: WHERE =NULL malfunction in release 7.2