I've been thinnking how to improve autovacuum so that we can convince
more people that it can be enabled by default. Here are my thoughts.
There are two areas of improvements:
1. scheduling, and
2. process handling, i.e., how to have multiple vacuum processes running
at any time.
I ripped
On Sunday 14 January 2007 05:18, Alvaro Herrera wrote:
I've been thinnking how to improve autovacuum so that we can convince
more people that it can be enabled by default. Here are my thoughts.
There are two areas of improvements:
1. scheduling, and
2. process handling, i.e., how to have
While we are talking autovacuum improvements, I'd like to also see some
better
logging, something that is akin to the important information of vacuum
verbose being logged to a table or baring that the error_log. I'd like to be
able to see what was done, and how long it took to do for
Simon Riggs wrote:
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
Christopher Browne wrote:
Seems to me that you could get ~80% of the way by having the simplest
2 queue implementation, where tables with size some threshold get
thrown at the little table queue, and tables above
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Log Message:
---
Add support for xmlval IS DOCUMENT expression.
I don't think I trust your reverse-listing of IS DOCUMENT; you need
parens around the argument to be sure it is parsed the same way next
time, if it's not a trivial expression.
First, thanks for working on this. I hope to be helpful with the design
discussion and possibly some coding if I can find the time.
My initial reaction to this proposal is that it seems overly complex,
however I don't see a more elegant solution. I'm a bit concerned that
most users won't
Alvaro Herrera [EMAIL PROTECTED] writes:
I've been thinnking how to improve autovacuum so that we can convince
more people that it can be enabled by default. Here are my thoughts.
There are two areas of improvements:
1. scheduling, and
2. process handling, i.e., how to have multiple vacuum
Tom Lane wrote:
Actually the reason it's not enabled by default today has nothing to do
with either of those; it's
3. Unexpected side effects on foreground processes, such as surprising
failures of DROP DATABASE commands. (See archives for details.)
The referred to thread starts here:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, right. The mentioned problems are:
* manual ANALYZE issued by regression tests fails because autovac is
analyzing the same table concurrently.
This problem might have gone away since then --- I think we are now
taking a lock to ensure only one
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
I've been thinking how to improve autovacuum so that we can convince
more people that it can be enabled by default.
I would like to see it enabled by default too, however the reason it
isn't already enabled by default is that it caused
Tom Lane wrote:
* contrib tests fail in their repeated drop/create database operations
because autovac is connected to that database. (pl tests presumably
have same issue.)
The DROP is at risk, but CREATE is also at risk because autovac feels
free to connect to template0. (One of the
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Possibly we could handle these by extending create/drop db to check
whether a process-connected-to-the-target-db is an autovac, and if so
send it a SIGINT and wait for the process to terminate, instead of
failing.
Hmm, I can see
Tom Lane wrote:
As near as I can tell, you're using CopyErrorData not because you
need an actual copy but just because elog.c doesn't export any other
API to let you see the current sqlerrorcode. Perhaps adding a
function to return the top stack entry's sqlerrorcode would be a
better API
On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote:
I don't think they need to be integrated any time soon, but if we were
to design pg_dump and pg_dumpall from scratch, it seems more logical to
use a single program
On thinking about this some more, it might be useful to factor much of
Alvaro Herrera wrote:
Hmm, I can see having DROP DATABASE just stopping the autovacuum
(since the work will be thrown away),
For that same reason DROP DATABASE could just cut all connections to the
database. Or at least queue up and wait until the session is over.
(The latter would
We need to decide on how to handle encoding information embedded in xml
data that is passed through the client/server encoding conversion.
Here is an example:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
pg_av_igroupmembers
groupid oid
month int
dom int
dow int
starttime timetz
endtime timetz
This seems to assume that the start and end time for an interval will be
on
Peter Eisentraut [EMAIL PROTECTED] writes:
Looking at the send/receive functions for the text type, they
communicate all data in the server encoding, so it seems reasonable to
do this here as well.
Uh, no, I'm pretty sure there's a translation to the client encoding.
It's in a subroutine not
18 matches
Mail list logo
