Julie Nishimura <juliezain@xxxxxxxxxxx> 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
