Обсуждение: PG_DUMP too slow...

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


im 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
.........................................


TIA

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
>
> im 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

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
> >
> > im 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..

>
> 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.

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