See my other reply, but the problem was that I had a foreign key
constraint between an integer and varchar. (The column was a varchar and
the foreign key was an integer field). Seems to me postgres shouldn't
have allowed me to do this at all, but I guess it did a slow automatic
type conversion.
Aha! Thanks for the reply, because it got me thinking, and I reexamined
the schema and discovered that the problem was that we had a foreign key
constraint involving two columns of different type (varchar vs. integer!).
[Yeesh.] I think the type conversion was what was making reindexing (not
to m
Yuji Shinozaki <[EMAIL PROTECTED]> writes:
> Then the problem is that
> reindexing takes a very long time. One particular index is taking on the
> order of 12 hours to finish.
Seems like a lot. What is the index definition exactly, and how many
rows in the table? If it's a btree, have you tried
On Thu, 14 Aug 2003, Yuji Shinozaki wrote:
>
> I have two questions about restoring and moving databases (in pg 7.3), to
> which I have not been able to find a suitable answers in the documentation
> (and searching the list archives has been painfully slow and fruitless).
>
> 1) What is the fastes
I have two questions about restoring and moving databases (in pg 7.3), to
which I have not been able to find a suitable answers in the documentation
(and searching the list archives has been painfully slow and fruitless).
1) What is the fastest way to restore a database *with indexes*?
We have s
