Thanks to Mr. Nasby & others for these references & input.
Indeed. I'm rather sure we don't have tables updated heavily enough to
warrant any adjustments to autovacuum, or to do extra 'vacuuming' of the
database. So I'll be leaving it alone (i.e. there's nothing broke so no
fixes needed!)
-
On 10/29/15 5:01 PM, Thomas Kellerer wrote:
So no harm in keeping it enabled - plus this smells like premature
optimization.
I would not touch this unless you _really_ see a performance problem
that is cause by autovacuum on that database.
Moreso, if you think the problem is autovacuum (in this
Jim Longwill schrieb am 29.10.2015 um 22:43:
Ok. The reason I wanted to experiment with autovacuum disable for
'ddev2' database is that it is a mostly read-only database -- to
support querying from our web apps. I.e. there are only 1 or 2 small
tables ever updated all day on it, and only about
On 10/29/2015 2:43 PM, Jim Longwill wrote:
Ok. The reason I wanted to experiment with autovacuum disable for
'ddev2' database is that it is a mostly read-only database -- to
support querying from our web apps. I.e. there are only 1 or 2 small
tables ever updated all day on it, and only about 2
Ok. The reason I wanted to experiment with autovacuum disable for
'ddev2' database is that it is a mostly read-only database -- to support
querying from our web apps. I.e. there are only 1 or 2 small tables
ever updated all day on it, and only about 20 or so records total per
day (compared to
Adrian Klaver writes:
> On 10/29/2015 01:35 PM, Jim Longwill wrote:
>> ... I'm always getting this error:
>> ERROR: parameter "autovacuum" cannot be changed now
> Controls whether the server should run the autovacuum launcher
> daemon. This is on by default; however, track_counts must also
On 10/29/2015 01:35 PM, Jim Longwill wrote:
Mr. Pierce, others,
I spoke too soon on this. I'd like to do your alter database.. command
but it isn't working. I've tried:
postgres=# ALTER DATABASE ddev2 SET autovacuum = off;
both as 'postgres' user, and the ddev2 owner user (which has owner
pr
Mr. Pierce, others,
I spoke too soon on this. I'd like to do your alter database.. command
but it isn't working. I've tried:
postgres=# ALTER DATABASE ddev2 SET autovacuum = off;
both as 'postgres' user, and the ddev2 owner user (which has owner
privs), and I'm always getting this error:
Ok,
Thanks! I think the ALTER DATABASE.. commands will work well for what
I'm doing now. I want to experiment with one database (doing manual
vacuuming, etc.) while leaving the other databases undisturbed.
Regards,
--Jim Longwill
On 10/29/2015 12:36 PM, John R Pierce wrote:
On 10/29/2015 12
On 10/29/2015 12:14 PM, Tom Lane wrote:
Might be better to settle for configuring specific large tables using
per-table vacuum settings, and not sweat the small stuff at a per-DB
level.
indeed, since you ALSO need to vacuum the system tables occasionally, or
things go pear-shaped if you do lot
John R Pierce writes:
> On 10/29/2015 11:52 AM, Jim Longwill wrote:
>> I would like to do a different vacuum configuration on ddev2 than on
>> ddev1, such as turning off autovacuum, etc. How do I do this? E.g.
>> how do I turn off autovacuum on one database .. using different
>> postgres.conf
On 10/29/2015 11:52 AM, Jim Longwill wrote:
I have a question about Postgres management. Our situation is
probably similar to many data shops.
We have one (Linux) server, and one Postgres installation (v9.4),
hence one Postgres process-daemon set running on the server, but we
have multiple d
I have a question about Postgres management. Our situation is probably
similar to many data shops.
We have one (Linux) server, and one Postgres installation (v9.4), hence
one Postgres process-daemon set running on the server, but we have
multiple databases created: ddev1, ddev2, ddev3.
I w
13 matches
Mail list logo
