Julie Nishimura <juliezain@hotmail.com> writes:
> 1) This is the 8.3 source:
> select * from pg_ts_dict;
> ...
> english_stem_nostop | 21960 | 10 | 11282 | language = 'english'
> hwsplit | 21960 | 10 | 22342 |
> hwsplit_only | 21960 | 10 | 22342 | returnreplaced = 'false', keeporig = 'false'
OK, so you have some non-built-in text search objects in your 8.3
installation. That's fine, but the dump/restore process should certainly
have included commands to recreate those objects in the new database.
Did you ignore any errors during the dump or restore? (Trying to run
the restore as a non-superuser could well have led to failure to restore
these objects, for instance, but you'd have gotten errors.) Did you perhaps
do a selective dump or restore? (For example, excluding whatever schema
21960 is would've led to excluding these objects.)
If you're not real sure about the errors angle, I'd suggest retrying
the process to see. You could use "pg_dump -s" to dump only schema
not data, so as to make that faster --- any relevant errors should
still occur.
I'm a bit confused by the initial report, too. If you are missing
the text search configuration(s) your application needs, that should
lead to query errors, not just things running slower. What exactly
is going wrong?
> Unfortunately, I am not sure about tsearch2,
psql's "\dx" would tell you what extensions are installed in the
8.3 database.
regards, tom lane