Well, I'll be dipped! More below;
Tom Lane <tgl@sss.pgh.pa.us> writes:
> On further analysis, it seems the problem is dependent on the exact
> ordering of the inputs to the qsort function. So not only do you need
> maintenance_work_mem to be large enough that the code will try to use
> qsort, but the physical order of the rows in the table matters.
> I suspect that you are testing on an 8.0 table with a different physical
> row order --- if you drop the table and reload it from the same dump you
> loaded into 8.1, does it get slow?
Tom, your theory is correct. If we had to build that index from
scratch on 8.0, with the data ordered as it was when I made the
original dump, it would have stalled all the same.
I just reproduced this on an 8.0.3 box.
FYI
--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant
305 321-1144 (mobile http://www.JerrySievers.com/