Re: PG_DUMP too slow...
On Friday 09 May 2003 7:08 pm, jerome wrote:
im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump behaves
like this... hheehheim working on a 4 Processor , RH7.3.. w/ postgresql-7.2.1-5 sitting on
it...can someone tell me what happened?
btw i tried to place a -v option these are the outputs..
pg_dump: saving database definition
pg_dump: last built-in oid is 16554
pg_dump: reading user-defined types
pg_dump: reading user-defined functions
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined tables
.........................................
1. Can you give us a copy of the precise command-line you are using and also a
select count(*) and \dt on the table in question?
2. Does this problem happen only on this table, or all tables?
3. Does this happen when dumping schema only (--schema-only)?
I do seem to remember some bug-fix in pg_dump in the 7.2 series, might be
worth checking the release notes section of the online manuals.
--
Richard Huxton
Import Notes
Reply to msg id not found: 200305100208.53025.jerome@gmanmi.tvReference msg id not found: 200305100208.53025.jerome@gmanmi.tv
On Friday 09 May 2003 9:52 pm, jerome wrote:
On Friday 09 May 2003 18:27, Richard Huxton wrote:
On Friday 09 May 2003 7:08 pm, jerome wrote:
im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump
behaves like this... hheehhe
1. Can you give us a copy of the precise command-line you are using and
also a select count(*) and \dt on the table in question?SELECT count(*) from dc_teksbak ;
count
-------
2
(1 row)i have 717 tables...
2. Does this problem happen only on this table, or all tables?
i tried it with other tables it works reacts the same...
im dumping the table..pg_dump mydb -t dc_teksbak > dc.out
Well, the options are supposed to go before the database name, but pg_dump
should cope. Very odd.
Assuming you can select the contents of dc_teksbak I think we can rule out any
problems with the database itself.
Some things it might be worth checking/trying (in this order I'd suggest):
1. Make sure you don't have an old installation with an old pg_dump (pg_dump
--version)
2. Try with --data-only option
3. Try with --schema-only option
4. Make sure no other transactions are active. This shouldn't matter, but I'm
trying to rule things out.
5. Restart the postmaster (with pg_ctl)
6. Create a new test database, make sure you can dump from that.
--
Richard Huxton
Import Notes
Reply to msg id not found: 200305100452.07003.jerome@gmanmi.tvReference msg id not found: 200305100208.53025.jerome@gmanmi.tv
On Friday 09 May 2003 18:27, Richard Huxton wrote:
On Friday 09 May 2003 7:08 pm, jerome wrote:
im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump behaves
like this... hheehheim working on a 4 Processor , RH7.3.. w/ postgresql-7.2.1-5 sitting on
it...can someone tell me what happened?
btw i tried to place a -v option these are the outputs..
pg_dump: saving database definition
pg_dump: last built-in oid is 16554
pg_dump: reading user-defined types
pg_dump: reading user-defined functions
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined tables
.........................................1. Can you give us a copy of the precise command-line you are using and
also a select count(*) and \dt on the table in question?
SELECT count(*) from dc_teksbak ;
count
-------
2
(1 row)
i have 717 tables...
2. Does this problem happen only on this table, or all tables?
i tried it with other tables it works reacts the same...
im dumping the table..
pg_dump mydb -t dc_teksbak > dc.out
3. Does this happen when dumping schema only (--schema-only)?
no. im dumping the schema and data..
Show quoted text
I do seem to remember some bug-fix in pg_dump in the 7.2 series, might be
worth checking the release notes section of the online manuals.