Alvaro Herrera wrote:
When I saw the manitou-mail.org stuff some days ago I was curious -- how
feasible would it be to host our web archives using a database of some
sort, instead of the current mbox-based Mhonarc installation we use,
which is so full of problems and limitations?
I wondered
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Its because we eliminated the -patches mailing list.
Yeah, I think this is most probably explained by repeat postings
of successive versions of large patches. Still, Ron might be on to
something. I had not considered message
Noah Freire wrote:
On Wed, Oct 29, 2008 at 4:46 PM, Matthew T. O'Connor [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Is the table being excluded? (see the pg_autovacuum system table
settings)
there's an entry for this table on pg_autovacuum, and it's enabled
Noah Freire wrote:
2008-10-29 11:09:03.453 PDTDEBUG: 0: accounts: vac: 16697969
(threshold 650), anl: 16697969 (threshold 12048)
2008-10-29 11:09:05.610 PDTDEBUG: 0: accounts: vac: 16699578
(threshold 650), anl: 16699578 (threshold 12048)
2008-10-29 11:10:03.563
Tom Lane wrote:
I think the subtext there is that the Linux kernel hackers hate the SysV
IPC APIs and wish they'd go away. They are presently constrained from
removing 'em by their desire for POSIX compliance, but you won't get
them to make any changes that might result in those APIs becoming
Bart Grantham wrote:
Forgive me if this has been beaten into the ground, but my team and I
couldn’t find much conclusive study or posts on this issue. To make a
long story short: we’re experiencing Xeons as 50% slower than Opterons,
even when the Xeon has twice as much cache and a slight
Adrian Klaver wrote:
On Monday 04 August 2008 11:04:00 pm Robert Shaw wrote:
WARNING: database mydb must be vacuumed within 177009986 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
mydb.Which is reason I ask the question, is full vacuum backup useful
for
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
BTW, what version of PostgreSQL is this? Database-wide vacuum is no
longer required for XID wraparound issues. I think this was an 8.3
change but might have happened in 8.2, I don't remember.
8.2. But you could still get
Andy Anderson wrote:
However, being a GUI-oriented person I haven't noticed management tools
comparable to phpMyAdmin (for web) and CocoaMySQL (for Mac). Perhaps
someone can enlighten me?
(Yes, I've tried pgAdmin, but it's not quite ... right. I can't say why
at the moment, I should probably
D. Dante Lorenso wrote:
Andrew Sullivan wrote:
I don't think it's odd at all. In my view, the people who think
enums are a
good datatype for databases are exactly the sorts who'd think that their
data is as static as this poor understanding of the vagaries of
individuals'
sex (gender is a
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
D. Dante Lorenso wrote:
Or, here's another way to look at it ... make it easier to modify ENUM
datatypes because we all know that you will eventually need that
feature whether you males, females, and unknowns think so or not.
+1
Added
Any chance we can an rpm for the plpgsql debugger to the rpms at
http://yum.pgsqlrpms.org/ ?
It would make it easier to install on systems that installed PGSQL from
rpm rather than from source.
Matt
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
Stuart Brooks wrote:
It'll take a few minutes but I'll try and get the information to you. A
summary is:
Process 1:
- writing 50 rows/second, 1 row/transaction.
- every so often delete 100 rows
Process 2:
- running ANALYZE VERBOSE and pg_total_relation_size every second
The result is that
Jeremy Harris wrote:
Chander Ganesan wrote:
Inserts don't generate dead tuples, and AVD looks at obsolete
tuples.. As such, I wouldn't expect AVD to kick off until after you
did a mass delete...assuming that delete was sizable enough to
trigger a vacuum.
Ah, that would explain it -
Joshua D. Drake wrote:
dvanatta [EMAIL PROTECTED] wrote:
What's up with 3 of the 7 being from Pennsylvania? What's the
connection?
Its the closest the cult of the elephant will get to jersey.
Whoa now, them's fightin' words. Come on over and you me, Tony, Paulie
and Silvio will have a
Pavel Stehule wrote:
pgbench test - default configuration
Verze 7.3.15 7.4.13 8.0.8 8.1.4 8.2.beta1 8.3beta1
tps 311 340 334 398 423 585
but pgbench is simple test and thise numbers hasnot great value.
Was that the same version of pgbench each time? Or was it
Robert Fitzpatrick wrote:
Now my question, would it be better to create one index with all columns
in the table -or- a separate index for each column field? I was assuming
the latter, but would the index with all columns be beneficial as well?
Generally it's much better to have an index deal
Joshua D. Drake wrote:
The PostgreSQL Conference Fall 2007 to date, has been a huge success. Of
course we haven't actually held the conference yet but already we have a
strong line of speakers and sponsors confirmed.
[ snip ]
I can't attend, but wish I could, is there going to be a web cast?
Bruce Momjian wrote:
Added to TODO:
* Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have a restore of a pg_dump somehow use it
http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php
Would it not also make sense to use this ability for
Tomasz Rakowski wrote:
I have problem with frequently updated table (around 30.000 records and
1000 updates/minute, few indexes).
After a while all queries to that table become much slower then at the
begining
(the number of records in the table is quite stable all the time).
I can see that
Porell, Chris wrote:
I have recently migrated a Postgres database from 7.4 running on gentoo to
8.1 running on SLES 10. I migrated the data using pg_dump and then running
the SQL in psql. The old server was a dual AMD opteron 2.6 GHz machine with
a RAID 5 array and 4GB memory. The new machine
Paolo Bizzarri wrote:
my name is Paolo Bizzarri and I am a developer of PAFlow, an document
tracking and management system for public administrations.
We use postgres as a backend, and we are experimenting some corruption
problems on openoffice files.
As our application is rather complex (it
OK, do you have the stats system enabled also? You require at least
row_level stats for autovacuum to work.
Schwenker, Stephen wrote:
I'm sure. That column is null for all tables in my databases accept for
the few tables that I've vacuumed manually.
Any other suggestions? :)
I don't think he's looking for progress information, I think he is
looking to be able to insert in chunks, which I don't know much about,
but I think the some of the binary types (bytea or blob) support this.
Anyone?
Bruce Momjian wrote:
Sorry, I know of no way to get a status bar that shows
Alvaro Herrera wrote:
I'd like to hear other people's opinions on Darcy Buskermolen proposal
to have a log table, on which we'd register what did we run, at what
time, how long did it last, how many tuples did it clean, etc. I feel
having it on the regular text log is useful but it's not good
Csaba Nagy wrote:
Other thing, how will the vacuum queue be populated ? Or the queue here means
nothing, all workers will always go through all tables to pick one based on their own
criteria ? My concern here is that the current way of checking 1 DB per minute is not
going to work with
Csaba Nagy wrote:
On Tue, 2007-01-09 at 17:36, Csaba Nagy wrote:
On Tue, 2007-01-09 at 17:31, Matthew T. O'Connor wrote:
Without getting into all the details, the autovacuum naptime is a GUC
variable right now, so it can be much more frequent than the current
default which is 60
Alvaro Herrera wrote:
To be frank, I'm not sure I understand what you're saying here. I'm
sure more analysis is good; that's easy to agree with.
However, I don't want to be trapped in a design that's too hard to
implement, or too hard for DBAs to manage.
+1
There have been proposals to
Russell Smith wrote:
Alvaro Herrera wrote:
I intend to work on the maintenance window idea for 8.3. I'm not sure
if I'll be able to introduce the worker process stuff in there as well.
I actually haven't done much design on the stuff so I can't say.
What does a maintenance window mean? I
to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Matthew T. O'Connor
V.P. Operations
Terrie O'Connor Realtors
201-934-4900
begin:vcard
fn:Matthew O'Connor
n:O'Connor;Matthew
org:Terrie O'Connor Realtors
adr:;;75 E. Allendale Rd;Saddle River;NJ;07450
Csaba Nagy wrote:
[snip]
I think the idea is to edit the postgresql.conf file on the fly and send
a SIGHUP to the postmaster. I haven't ever heard of anyone doing that,
but I don't see any reason why it wouldn't work.
It works, I did it for a while with the statement_timeout to
Ed L. wrote:
Does autovac maintain its state/counters across restats as to who
need to be vacuumed/analyzed? Or does killing autovac cause it
to reset the counters for the vacuum/analyze threshholds?
Depends on the version. The contrib autovacuum does not maintain state
through a restart.
Glen Parker wrote:
I would like a way to run the autovacuum daemon on demand
periodically. Every night at 2 AM, for example.
Anybody know if this is possible? If not, it's a feature request :-)
Autovacuum can be enabled / disabled on the fly using the GUC settings.
Perhaps you can write
MaXX wrote:
There are 10-15 postmaster processes running which use all the CPU
power.
A restart of tomcat and then postgresql results in the same situation.
Some postgres processes are in DELETE waiting or SELECT waiting.
VACUUM runs through in just about 1-2 seconds and is run via cron
every
snacktime wrote:
This has worked well so far but it's a real pain to manage and as we
ramp up I'm not sure it's going to scale that well. So anyways my
questions is this. Am I being too paranoid about putting all the data
into one set of tables in a common schema? For thousands of clients
Gene wrote:
For some reason when I restart postgresql the autovacuum = on is ignored
and when I do a show all it is showed as being off. It did not always do
this until recently. What is the best way to diagnose what maybe
happening? Are there other config files which may prevent it from being
Chris wrote:
You need to install setup tsearch2.
I have a small article about how to do that here:
http://www.designmagick.com/article/27/
Nice article, very clear and concise, however one small nit. At the end
of page I don't think you need the vacuum full, vacuum may or may not be
Chris wrote:
aBBISh wrote:
You need to install setup tsearch2.
I have a small article about how to do that here:
http://www.designmagick.com/article/27/
Also on page 3 you say, (normal indexes will only index the first 255
characters of a 'text' field).
Is that true?
Jim C. Nasby wrote:
Take a look at http://pgfoundry.org/projects/pgpitrha/
I had already seen this however it says that this project has yet to
release any files, so I thought it was a dead project. Am I missing
something?
Also, note that in 8.1, you have to manually archive the last WAL
Tom Lane wrote:
Matt matthew@zeut.net writes:
I'm getting the following error on PGSQL 8.0.8 server that I admin. I
don't think this is a hardware problem but I'm not sure. Anyway in the
logfile I'm constantly getting this:
ERROR: xlog flush request 2/13CEA8AC is not satisfied ---
Francisco Reyes wrote:
Using 8.1.4
Have autovacuum running and it shows on the logs as running.
Ever couple of days in the last week when I tried to run vacuum analyze
postgresql complained that I needed to increase my fsm_pages.
I am going to start scheduling vacuum analyze in crontab.. but
Wayne Conrad wrote:
On Thu, Aug 03, 2006 at 05:03:35PM -0400, Matthew T. O'Connor wrote:
I have it set as follows:
archive_command = 'rsync -a %p backup_server:/pgsql_pitr/%f'
Any comments as to whether or not this is a *good* choice?
Are you also doing the dance with pg_start_backup
Chander Ganesan wrote:
Matthew T. O'Connor wrote:
I have done some googling for real world archive_command examples and
haven't really found anything. The example in the PGSQL Docs are
qualified by (This is an example, not a recommendation, and may not
work on all platforms.)
I have it set
Wayne Conrad wrote:
On Fri, Aug 04, 2006 at 11:04:03AM -0400, Matthew T. O'Connor wrote:
Wayne Conrad wrote:
Are you also doing the dance with pg_start_backup(), doing a file copy
Yes, of course. Is there another way?
Not that I know of. I'm embarassed I ask, since you
I'm setting up PITR for a client and have a few questions.
I have done some googling for real world archive_command examples and
haven't really found anything. The example in the PGSQL Docs are
qualified by (This is an example, not a recommendation, and may not work
on all platforms.)
I
Tom Lane wrote:
The reason I didn't patch it myself is that I'm not quite clear on what
*should* be happening here. What effect should a large delete have on
the ANALYZE threshold, exactly? You could argue that a deletion
potentially changes the statistics (by omission), and therefore inserts,
Tom Lane wrote:
Dylan Hansen [EMAIL PROTECTED] writes:
I have been spending some time looking into how auto-vacuum is
performing on one of our servers. After putting the PostgreSQL logs
in debug I noticed that the threshold for ANALYZE was never being hit
for a particular table because
Well, to answer my own question, I hacked the source code of DBMail and
had it set the client encoding to LATIN1 immediately after database
connect, this seems to have fixed the problem.
Sorry for the noise,
Matt
Matthew T. O'Connor wrote:
I'm using DBMail running against PostgreSQL as my
Tino Wildenhain wrote:
Matthew T. O'Connor schrieb:
Well, to answer my own question, I hacked the source code of DBMail
and had it set the client encoding to LATIN1 immediately after
database connect, this seems to have fixed the problem.
You could also just have set the client_encoding
Daniel Verite wrote:
Matthew T. O'Connor wrote:
The basic setup is that Postfix hands the email to a program called
dbmail-smtp which parses and insert the message into the database.
DBMail doesn't know anything about encoding.
That's precisely what SQL_ASCII is for. Why
Daniel Verite wrote:
IMHO they fail to draw the proper conclusion, which is that
either the raw mail should be stored as either as a binary object,
or as a text field in a database with SQL_ASCII encoding, in both
cases providing the level of transparency that they need by design,
their purpose
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
They have talked about changing the messageblks to binary instead of
text. They said that one of their main objections is that bytea data is
not compressed. I'm not sure that's true, but I don't see anything in
the docs about
I'm using DBMail running against PostgreSQL as my mailstore for our
company network. I recently converted our company database from
SQL_ASCII to UTF8 as I thought this would be a *good thing*.
The problem now is that I think I'm loosing emails because in my
postgresql logs I get this:
Hey all, I was just wondering if there were any plans to get 8.1.4
release in the near future. I'm seeing semi-frequent out of memory
errors that are related to a bugfix that Tom put in post 8.1.3. (Yes I
know I can compile from source, but I'd rather not do that on my
production server.)
Tony Lausin wrote:
[ rotfl... ] MySQL will fall over under any heavy concurrent-write
scenario. It's conceivable that PG won't do what you need either,
but if not I'm afraid you're going to be forced into Oracle or one
of the other serious-money DBs.
That's a scary idea - being forced into
Right, I think there has been discussion about this and general
agreement that the current autovacuum logging options are less than
ideal to put it mildly. Unfortunately, I don't think there has been any
action by anyone to do something about it. I hope to work on this at
some point, but
The table has 6800 rows over 18000 pages, and is getting a
minimum of many tens of thousands of updates per day with
queries like this:
If you're updating that much, how often are you running
'analyze'? Are you running autovacuum? How often?
I count on the built-in autovacuum to do do analyzes
Thomas F. O'Connell wrote:
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for verification
purposes) once the dump completes. The process is roughly:
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
We
Are you sure that is the exact command line you are using for
autovacuum? I'm not sure it will work like that, I believe the the -s
and -S options require a value to be given.
Anyway, a few things you can do. It sounds like the table isn't getting
vacuumed frequently enough for you, you
Hello all,
I run a nightly vacuumdb -a -z on my production server. The output of
the command is emailed to me every night. Today while checking my email
I received this:
vacuumdb: vacuuming database postgres
vacuumdb: vacuuming of database postgres failed: ERROR: out of memory
DETAIL:
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
PostgreSQL 8.1.0 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
3.3.3 20040412 (Red Hat Linux 3.3.3-7)
... and this should definitely make you nervous. We don't release
update versions for idle amusement. Get onto
If you really are just inserting, and never updating or deleting, then you
will never need to vacuum the table, rather you will just need to ANALYSE
the table. If you use autovacuum that is exactly what it will do.
As for Reindex, I'm not entirely sure, I don't think you would benefit
from
Also, somebody made a real good point about rolled-back insertions.
Even if the only command you ever apply to the table is INSERT, you
could still have dead rows in the table if some of those transactions
occasionally roll back.
hmm... That's true. I don't think autovacuum doesn't anything
Exactly which version of 8.0.x? There was a bug fixed around 8.0.5 or
so Prevent core dump in contrib version of autovacuum when a table has
been dropped. Per report from daveg (not his patch, though).
The version of autovacuum in 8.1 is a fairly different beast than the
contrib version,
Csaba Nagy wrote:
It's version 8.0.almost3, meaning that I used the 8.0 stable CVS branch
just before 8.0.3 was released. I will upgrade this data base to 8.1.x
(the latest released version at the time of upgrade) soon, so if the 8.1
version has the temporary table thing fixed that would be very
Jaime Casanova wrote:
But if VACUUM fixes the wraparound issue, shouldn't even a badly
configured autovacuum make the wraparound not be a problem in 8.1? Or did
I miss understand how this works?
but you can disable autovacuum (i do not why you can do something like
that but i guess someone
Jerry LeVan wrote:
Are there any (detailed) instructions available on how
to connect OpenOffice 2 and Postgresql 8.1.
I have the jdbc driver(s) from postgresql.org...
I am running FC4 and have access to DB's on a Mac
and the Linux box.
This would be a helpful thing to have. I know there is
Andrus wrote:
Jim,
Keep in mind that if analyze has never been run on a table the database
will assume 1000 rows, which is definately off from 122 rows.
autovacuum processes this tabele regularly.
I believed that autovacuum can update the row count to be real.
I think this is a poor
Vivek Khera wrote:
Another issue with autovacuum (haven't investigated the 8.1 version
yet) is that you can't make different threshhold settings for
different tables. For example, I have some tables that are a handful
of rows but are updated bazillions of times per day, and other tables
with
Couple of thing here:
1) Just because autovacuum is running, doesn't mean that it has actually
tried to vacuum a table. 5 minutes is the time that it sleeps in between
investigating activity to see if a vacuum is needed. If you want to see
if pg_autovacuum has actually tried to do anything you
Carlos Oliva wrote:
Thank you for your response Matthew. Currently I run pg_autovacuum with the
following scripts.
su -l postgres -c pg_autovacuum -D -U postgres /dev/null 21
Do you suggest that I could change it to something like the following:
su -l postgres -c pg_autovacuum -d2 -D -U
Brian Mathis wrote:
I just set up a new server and would like to use rpms to manage the
software on this one. I've done the compile from source thing most of
the time, but over time it seems to get messy.
I'm using CentOS 4.2, which only has packages for postgres 7.4, but I
very much want
Zlatko Matić wrote:
What needs to be configured in order autovacuum process be active?
I assume you are talking about the Windows version. If so, and if you
used the installer, then you don't need to do anything. It appears (at
least on my RC1 install) that autovacuum is enabled by
Wes Williams wrote:
Correct, the default setting for PostgreSQL 8.1 W32 value in postgresql.conf
is 'autovacuum' to 'on'.
You can see this and more settings in pgAdmin III by visiting 'Tools',
'Server Configuration', then the config file of your choice.
Now, if only I could setup my home to
Zlatko Matic wrote:
what is the schedule for releasing first official 8.1 ?
Ahh the eternal question. I believe the official answers, and always
will be: When it's ready. However seeing as they think they are just
about ready for Release Candidate stage, I would say, not too much
longer.
Florian Ledoux wrote:
An autovacuum deamon has been installed as a Windows service during
the setup of my PG 8.0.3 server on WinXP. I am surprised because I
believed that autovacuum was only available in 8.1 server. There is
no autovacuum_XXX parameters in postgresql.conf... How can I be sure
Zlatko Matić wrote:
For pg_dump minimum privilages is to have select right on tables.
For vacuumdb, one must be owner of tables or a superuser.
What are minimum rights for user that is trying to execute pg_autovacuum ?
Not sure exactly, you need to have permission to vacuum every table in
I know the installer will be a while, but can someone put up a
binary-no-installer type zip file on the server somewhere? I know this
is done for other releases.
Thanks,
Matt
Tony Caduto wrote:
Thanks Magnus, yes by default I meant binary since that is how the
majority of win32 software
Jan Wieck wrote:
On 8/9/2005 12:21 PM, Tom Lane wrote:
This reminds me I've forgot to ask, is there any other way of getting
rid of those ghost entries than via big load ?
Not at the moment. It might be worth teaching the pgstats code to
cross-check the activity list every so often, but
Audrey Bergeron-Morin wrote:
We've been having trouble with a pgSQL 8.0.3 install
on a WXP machine. Install goes fine, DB works until we
restart the machine, then we can't connect. First time
we thought something was corrupted because we had a
power outage, we uninstalled/reinstalled and it was
Bjørn T Johansen wrote:
How stable is the windows version of pgsql 8? Is it as stable as the Linux
version or
should I look elsewehere after a good sql srv for Windows?
This is a tough question to answer and you will probably get a wide
range or responses. Many people on these lists
Douglas McNaught wrote:
Brandon Metcalf [EMAIL PROTECTED] writes:
I've been looking at the auto vacuum daemon pgavd and it looks like
there hasn't been any development activity in a while. Does anyone
know that status of pgavd?
Also, I'd be interested in hearing how well it works and if
Phil Endecott wrote:
Matthew T. O'Connor wrote:
Indeed you have. I have head a few similar reports but perhaps none
as bad as yours. One person put a small sleep value so that it
doesn't spin so tight. You could also just up the sleep delay so
that it doesn't do this work quite so often
Phil Endecott wrote:
Matthew T. O'Connor wrote:
The integrated version of autovacuum that didn't make the cut before
8.0 avoids this problem since the autovacuum data is stored in the
database.
What is the status of this? Is it something that will be included in
8.1 or 8.0.n? I might
Phil Endecott wrote:
Following up on my own post from last night:
Could it be that there is some code in autovacuum that is O(n^2) in
the number of tables?
Browsing the code using webcvs, I have found this:
for (j = 0; j PQntuples(res); j++)
{
tbl_elem = DLGetHead(dbs-table_list);
Hello,
Not sure if this is a good place to ask this question, but it is the
general list
My company is looking for a way to get a list of all the names and phone
numbers with addresses for New Jersey. Does anyone know where / how I
can get this dataset? I have done some googling and
Thomas F. O'Connell wrote:
I have a web application backed by a PostgreSQL 7.4.6 database. It's
an application with a fairly standard login process verified against
the database.
I'd like to use pg_dump to grab a live backup and, based on the
documentation, this would seem to be a realistic
I have a (hopefully simple) question regarding locale.
I am migrating a postgresql database from a server running FC1
PostgreSQL 7.4 to a newer machine running FC2 and PostgreSQL 8.0. I
dumped the data from the old server using pg_dumpall and restored it to
the new server with no problems,
Richard Huxton wrote:
Joe Maldonado wrote:
Hello all,
I have a few somewhat simple questions
Does the postmaster vacuum it's internal (pg_*) tables? if not
what is the best way to vacuum them without having to vacuum the
entire db?
and how often is this recommended to be done?
No, and
Gaetano Mendola wrote:
Matthew T. O'Connor wrote:
Since you are running autovacuum I doubt the doing vacuumdb -a -z is 3
times a day buying you much. It's not a bad idea to do once in a while.
The reason is that I have few tables of about 5 milion with ~ 1
insert per
day. Even with setting
On Sun, 2004-10-03 at 21:01, Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
Christopher Browne wrote:
pg_autovacuum -d 3 -v 300 -V 0.5 -S 0.8 -a 200 -A 0.8
I'm not very familiar at all with appropriate settings for
autovacuum,
but doesn't the above
Thomas F.O'Connell wrote:
Well, I don't have a lot of databases, but I do have tens of thousands
of tables, many of which have hundreds of thousands of rows. I don't
know if that plays into things.
Number of rows is irrelevant, but the number of tables might not be. It
could be that the
Anony Mous wrote:
Great, I found the part of the docs referring to this (ch 27.11) however, it
refers to creating this file in the user's home directory. It seems this
part of the documentation is assuming I'm using *nix. In Windows, where
should this file be located? Also, .pgpass is an
Paul Tillotson wrote:
If pgautovacuum does ANALYZE and we can get most people to use
pgautovacuum, I think this problem will go away.
It does. We won't get most people to use it for 8.0 since it is still a
contrib project, but hopefully it will be built-in for 8.1.
Regular vacuum will (almost) never return your table to it's minimum
size. I don't think it's unreasonable for a table that is 4MB after a
vacuum full, to grow to 11MB, especially if it's a very active table.
The important question is does it keep growing? Or does it reach a
steady state size?
If you increase max_fsm_pages to a large enough number then the next
vacuum analyze will make all the pages with free space available to be
reused. A normal VACUUM does not actually reclaim space (unless it's at
the end of the table I think), it only marks the space as reuseable.
VACUUM FULL
Hey Bruce,
I assume this is the position we were talking about on the phone. I
sent you my resume that day, did you get it? Just wanted to confirm
since I didn't heard from you.
Matthew
On Wed, 2004-06-16 at 14:42, Bruce Momjian wrote:
[ BCC to hackers.]
SRA America, based in New York
On Wed, 2004-05-19 at 06:02, Peter Haworth wrote:
Is it possible/safe to compile the latest version of pg_autovacuum, and use
it with a 7.2.4 postmaster?
I know the better solution would be to upgrade everything, but that involves
a lot of work which we've managed to put off for a long time
More important than sleep value is the vacuum threshold. If for example
you are expecting to import 5000 rows of data, you can tell
pg_autovacuum to vacuum after every 5000 changes with like
pg_autovacuum -v 5000 -V 0
Matthew
On Wed, 2004-05-19 at 17:09, Carlos wrote:
Hello Forum,
I
On Tue, 2004-05-18 at 22:16, Bruce Momjian wrote:
Brian Hirt wrote:
I've having a strange issue with pg_autovacuum. I have a table with
about 4 million rows in 20,000 pages. autovacuum likes to vacuum
and/or analyze it every 45 minutes or so, but it probably doesn't have
more that
1 - 100 of 118 matches
Mail list logo
