During dump: function not found

From: Andrew Gould <andrewgould(at)yahoo(dot)com>
To: Postgres Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: During dump: function not found
Date: 2001-08-22 15:17:21
Message-ID: 20010822151721.93332.qmail@web13402.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

During a pg_dump, I got the following messages:

Notice: function "pgadmin_get_rows" is not dumped.
Reason: return type name (oid 87589805) not found.
Notice: function "pgadmin_get_sequence" is not dumped.
Reason: return type name (oid 87589772) not found.

Does this simply mean that these functions will not be
available if I restore from the dump file? Will these
messages haunt me down the road in other ways?

I'm assuming (dangerous, I know) that these functions
were created by PgAdmin rather than being a part of
PostgreSQL. I deleted all tables and views named
pgadmin* and am trying to weed out everything created
by PgAdmin.

Thanks,

Andrew Gould

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
>From pgsql-general-owner(at)postgresql(dot)org Wed Aug 22 11:18:41 2001
Received: from hotmail.com (f104.law4.hotmail.com [216.33.149.104])
by postgresql.org (8.11.3/8.11.4) with ESMTP id f7MF8xP17715
for <pgsql-general(at)postgresql(dot)org>; Wed, 22 Aug 2001 11:08:59 -0400 (EDT)
(envelope-from ulive1x(at)hotmail(dot)com)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 22 Aug 2001 08:08:55 -0700
Received: from 24.190.144.118 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 22 Aug 2001 15:08:55 GMT
X-Originating-IP: [24.190.144.118]
From: "Paul C." <ulive1x(at)hotmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: FTI is really really slow; what am I doing wrong?
Date: Wed, 22 Aug 2001 11:08:55 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F104VWDKpzxDPHprp5y00014a94(at)hotmail(dot)com>
X-OriginalArrivalTime: 22 Aug 2001 15:08:55.0517 (UTC) FILETIME=[5C9100D0:01C12B1C]
X-Archive-Number: 200108/671
X-Sequence-Number: 14055

Greetings,
I am trying to test out the performance of the contrib/fulltextindex
package and I am getting horrid performance results.
The Setup:
I created a simple table, ST (id SERIAL, body varchar(1024), which is to be
searched. I created the ST_FTI table, trigger and indices as per
instructions in the FTI readme and C file. To populate the table, I took a
flat text version of 'War and Peace' I found on the net, broke it up into
sentences and inserted each sentence into ST as a row. So I have about
38,000 sentences and my ST_FTI table is about 2 million rows.
The Test:
There is exactly one sentence (row) that has the strings 'Newton' and
'Kepler' in it. That is my target. For a straight select on ST:
select * from st where body ~* 'newton' and body ~* 'kepler';
the cost is 1100.41
BUT for an query using the FTI indices:
select s.* from st s, st_fti f1, st_fti f2 where f1.string
~ '^kepler' and f2.string ~ '^newton' and s.oid = f1.id
and s.oid = f2.id;
the cost becomes a staggering 80628.92!!! The plans are pasted at the end
of this message.
Now, I have all the indices created (on id of st_fti, on string of st_fti
and on oid of st). I cannot figure out why this is so much worse than the
straight query. Indeed, the cost to look up a single string in the st_fti
table is way high:
select * from st_fti where string ~ '^kepler';
costs 36703.40, AND its doing a Seq Scan on st_fti, even though an index
exists.
What am I doing wrong? Is it the sheer size of the st_fti table that is
causing problems? Any help would be greatly appreciated.
Thanks,
Paul C.

FTI search
NOTICE: QUERY PLAN:
Merge Join (cost=80046.91..80628.92 rows=110 width=28)
-> Sort (cost=41827.54..41827.54 rows=19400 width=24)
-> Hash Join (cost=1992.80..40216.39 rows=19400 width=24)
-> Seq Scan on st_fti f2 (cost=0.00..36703.40 rows=19400
width=4)
-> Hash (cost=929.94..929.94 rows=34094 width=20)
-> Seq Scan on st s (cost=0.00..929.94 rows=34094
width=20)
-> Sort (cost=38219.37..38219.37 rows=19400 width=4)
-> Seq Scan on st_fti f1 (cost=0.00..36703.40 rows=19400 width=4)
EXPLAIN

Plain search:
NOTICE: QUERY PLAN:
Seq Scan on st (cost=0.00..1100.41 rows=1 width=16)
EXPLAIN

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mitch Vincent 2001-08-22 15:28:04 Re: FTI is really really slow; what am I doing wrong?
Previous Message Peter Eisentraut 2001-08-22 15:12:23 Re: add, subtract bool type