Devrim Gündüz wrote:
Hi,
On Fri, 2007-04-06 at 01:23 -0400, Matthew T. O'Connor wrote:
The other thing to consider is that CentOS 5 has Xen built right in,
so you should be able run VMs without VMWare on it.
... if the kernel of the OS has Xen support, there will be no
performance penalty
Tom Lane wrote:
This means that a table could easily be full of dead tuples from failed
transactions, and yet autovacuum won't do a thing because it doesn't
know there are any. Perhaps this explains some of the reports we've
heard of tables bloating despite having autovac on.
I think this is
Michael Paesold wrote:
Matthew T. O'Connor schrieb:
Do we need a configurable autovacuum naptime at all? I know I put it
in the original contrib autovacuum because I had no idea what knobs
might be needed. I can't see a good reason to ever have a naptime
longer than the default 60 seconds,
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The only case I can think of where autovac might not work as well as
smartvacuum would be if you had a lot of databases in the cluster, since
autovacuum will only vacuum one database at a time.
It's conceivable that it'd make sense to
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I'd like to see something like VACUUM FULL WAIT. :)
Sounds like a deadlock waiting to happen :-(
AFAIK the general practice is to just accept the fact that vacuum can't
remove recently-dead tuples. You should look into whether
Russell Smith wrote:
I thought the plan was to change the ALTER TABLE command to allow vacuum
settings to be set.
That is my understanding too.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Richard Huxton wrote:
Simon Riggs wrote:
- improve RI check perf by caching small, static tables in each backend
- apply index filter conditions on index scan to avoid heap lookup
For fkey checks against a basically static table could you get away with
just checking the index and not the
