Unless I misunderstand, if stats_reset_on_server_start=off, these
(currently nonexistent autovacuum) stats would only be relevant for
autovacuum's VACUUM activity and not it's ANALYZE activity. In
which case, it seems ideal to keep autovacuum VACUUM stats
regardless of the GUC setting, while
Jeff Bohmer wrote:
I assumed (perhaps incorrectly) that you were talking about
maintaining the data in the theoretical / not yet in existence
autovacuum stats table through database restart, the stats system
already has a GUC var that dictates whether or not it dumps it's data
upon DB restart
Hello everybody,
I'm trying backup restore of DB with LO.
I backuped using as superuser :
pg_dump -d -o -F t -b -u database --file=database.tar
Because the superuser is not the DB owner, I create the DB on another
server (same os ans same version of PGSQL which is 7.4.8 ) :
CREATE DATABASE
AFAIK, a restart does not affect the VACUUMed-ness of anything.
Keeping these (currently nonexistent autovacuum) stats across
restarts would be helpful if stats_reset_on_server_start=on.
Sorry, got the meaning backwards. The above should be
stats_reset_on_server_start=OFF. And the below s
This sounds more and more like a good idea. I don't think there's any
need to maintain across dump/reload and / or database restart either.
The DBA can elect to keep or discard stats data across DB restart,
in fact I think the default value for this GUC var was set to true
for the 8.1 releas
Scott Marlowe wrote:
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/relo
On 11/10/05, Tom Lane <[EMAIL PROTECTED]> wrote:
Chris Hoover <[EMAIL PROTECTED]> writes:> Does anyone have a link to documents that describe the new partitioning that> is available in 8.1 (I look at the 8.1 docs but did not see any, but I may
> be blind :) )?http://www.postgresql.org/docs/8.1/stat
Chris Hoover <[EMAIL PROTECTED]> writes:
> Does anyone have a link to documents that describe the new partitioning that
> is available in 8.1 (I look at the 8.1 docs but did not see any, but I may
> be blind :) )?
http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html
It's not really a n
CG <[EMAIL PROTECTED]> writes:
> Can anyone surmise what this message is really saying?
> clusterdb: clustering of table "letter" in database "addata" failed: ERROR:
> could not access status of transaction 1696665057
> DETAIL: could not open file "/usr/local/pgsql/data/pg_clog/0652": No such
>
PostgreSQL 7.4 :
Can anyone surmise what this message is really saying?
clusterdb: clustering of table "letter" in database "addata" failed: ERROR:
could not access status of transaction 1696665057
DETAIL: could not open file "/usr/local/pgsql/data/pg_clog/0652": No such file
or directory
CONTE
Does anyone have a link to documents that describe the new partitioning
that is available in 8.1 (I look at the 8.1 docs but did not see any,
but I may be blind :) )?
I'd like to experiment with it and see if it can help with our data needs.
For those interested:
I need to be able to have a live
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
> Scott Marlowe wrote:
> >> I would appreciate an easy way to keep tabs on autovacuum's activity.
> >> A stat table seems like a practical way to have this info readily
> >> available.
> >>
> >> No need to keep values across dump/reloads, ri
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/reloads, right?
This sounds more and more like a good idea. I don't think there's a
On Thu, 2005-11-10 at 02:04, Jeff Bohmer wrote:
> >Another thought: How about adding something to the stats system
> >that an admin can turn on / off. Maybe anew relation called
> >pg_stat_autovacuum_activity this would detail the last vacuum, last
> >analyze, number of vacuums / analyzes in t
Hello
On Thu, 10 Nov 2005, murali segu wrote:
> i want to merge two databases how it is done plz help me
> thanQ
This should do the trick (under U*ix shell):
pg_dump -U username -h hostname source_db | psql -U username -h hostname
target_db
--
--Jyry
C|:-(C|:-/C|8-OC
please...tell me if there is possibility of
finding out the size of a record size in the specified table.
I need this Inorder to allocate the memory after
retrieving the records.
Pls suggest me.
Thanks,
Sandhya
Another thought: How about adding something to the stats system
that an admin can turn on / off. Maybe anew relation called
pg_stat_autovacuum_activity this would detail the last vacuum, last
analyze, number of vacuums / analyzes in the last 24 hours, last
month etc... I dunno, whatever pe
17 matches
Mail list logo
