Hi Adrian,
When I do a pg_dump with the following parameters /usr/bin/pg_dump -E
UTF8 -F c -b I get a file of 14GB in size.
From the man page of pg_dump
-F format, --format=format
Selects the format of the output. format can be one of the following:
c
output a custom archive suitable for
On Wed, 26 Mar 2008 13:02:13 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
The slowness is likely attributed to Vacuum's use of I/O. When vacuum
is running what does iostat -k 10 say?
Seems to be higher than normal - here is the output with vacuum run
without the other queries and the
Hey all,
I had posted sometime back asking for the best way to perform vacuum
with a lower priority - I did tune it up to a lower priority
and still noticed that the other database queries are slowing down
with a vacuum on one big table. I also tried to upgrade Postgresql to
8.0.15 as suggested
Hi all,
I have been searching for the best way to run maintenance scripts
which does a vacuum, analyze and deletes some old data. Whenever the
maintenance script runs - mainly the pg_maintenance --analyze script -
it slows down postgresql inserts and I want to avoid that. The system is
under
Hi Joshua,
You can use parameters such as vacuum_cost_delay to help this... see
the docs:
http://www.postgresql.org/docs/8.3/static/runtime-config-autovacuum.html
I am checking it out. Seems to be a nice option for vacuum - but wish
there was a way to change the delete priority or I will
On Fri, 2008-03-14 at 18:37 -0700, Tom Lane wrote:
That's only a little bit better. Read about all the bug fixes you're
Sure - will eventually upgrade it sometime - but it has to wait for
now :(
--
Vinu
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
I think you will find if you do it the right way, which is to say the
way that it is meant to be done with the configurable options, your
life will be a great deal more pleasant than some one off hack.
yeah I agree. The pg_maintanence script which calls vacuum and analyze
is the one of
[mailto:[EMAIL PROTECTED]
Sent: 24 November 2006 17:05
To: Guido Neitzer
Cc: Gopal; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Postgres scalability and performance on windows
On Fri, 24 Nov 2006 09:22:45 +0100
Guido Neitzer [EMAIL PROTECTED] wrote:
effective_cache_size = 82728
width=4) (actual
time=0.005..0.024 rows=10 loops=1)
Filter: (typeofdataid
= 1)
Total runtime: 15.871 ms
Gopal
getting as the
limit on windows or should I be looking at some other params that I
might have missed?
Thanks,
Gopal
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more
10 matches
Mail list logo
