Re: Does pg_dump ignore indexes?

From: "Vilson farias" <vilson(dot)farias(at)digitro(dot)com(dot)br>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>, "EDUARDO TRIERWEILER Naschenweng" <eduardo(dot)naschenweng(at)digitro(dot)com(dot)br>, "SIMONE Carla MOSENA" <simone(dot)mosena(at)digitro(dot)com(dot)br>
Subject: Re: Does pg_dump ignore indexes?
Date: 2000-11-21 16:37:27
Message-ID: 002201c053d9$55bc8240$98a0a8c0@dti.digitro.com.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

: "Vilson farias" <vilson(dot)farias(at)digitro(dot)com(dot)br> writes:
: > I've been testing hardly and now I found something interesting : these
: > errors only happen when model/data are imported with pg_dump help, that
is,
: > all indexed fields are sequencially scanned when I do a select from some
: > pk-indexed table, but if model/data where created/imported without
pg_dump,
: > then everything works fine. Does anyone know why this is happening?
:
: Have you done a VACUUM ANALYZE after loading the pg_dump output?
: It looks to me like the planner may not have statistics about the table...
:
: regards, tom lane
:

I did a vacuum analyse, but my selects were still doing seq scans over
tables. After that, I'd executed VACUUM again, then I discovered that VACUUM
was not reaching the end of analysis, it losts connection with database,
after a lot of error reports. I can't figure out what's happening, could you
give me some light?

Check this out :

[postgres(at)dgtao backup]$ /usr/bin/vacuumdb --analyze --verbose -d relatorio

NOTICE: --Relation pg_type--
NOTICE: Pages 4: Changed 0, reaped 1, Empty 0, New 0; Tup 274: Vac 0,
Keep/VTL 0/0, Crash 0, UnUsed 10, MinLen 105, MaxLen 114; Re-using:
Free/Avail. Space 1180/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.03u sec.
NOTICE: Index pg_type_typname_index: Pages 10; Tuples 274: Deleted 0. CPU
0.02s/0.01u sec.
NOTICE: Index pg_type_oid_index: Pages 5; Tuples 274: Deleted 0. CPU
0.00s/0.01u sec.
... lots of...
NOTICE: --Relation cham_chamada--
NOTICE: Rel cham_chamada: TID 4/1: OID IS INVALID. TUPGONE 1.
NOTICE: Rel cham_chamada: TID 4/2: OID IS INVALID. TUPGONE 1.
....3 to 56...
NOTICE: Rel cham_chamada: TID 4/57: OID IS INVALID. TUPGONE 1.
NOTICE: Rel cham_chamada: TID 4/58: OID IS INVALID. TUPGONE 1.
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
connection to server was lost
vacuumdb: vacuum failed

===========================================================
in psql :

relatorio=# \d cham_chamada
Table "cham_chamada"
Attribute | Type | Modifier
---------------+-------------+----------
chave | integer | not null
identificacao | integer | not null
dt_inicial | timestamp | not null
indicadora | integer |
cod_categoria | integer |
identidadea | varchar(20) |
dt_final | timestamp |
juntor | integer |
indicadorb | integer |
identidadeb | varchar(20) |
flg_chamada | char(1) |
flg_liberacao | char(1) |
Index: xpkcham_chamada

My best regards,
José Vilson de Mello de Farias
Dígitro Tecnologia - Brazil

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Eisentraut 2000-11-21 16:37:42 Re: Trying to build 7.0.3 on SCO 5.0.4
Previous Message Peter Eisentraut 2000-11-21 16:32:52 Re: I loose my history keys using psql...