Re: Curious run-away index build on upgrade to 8.1.3

Jerry Sievers <jerry(at)jerrysievers(dot)com> writes:
> Platform is Solaris 2.9

I think this might be the key...

I can reproduce an unreasonably long runtime if I use src/port/qsort.c
(as we do on Solaris), but not with glibc's version of qsort. I think
you are seeing the poor-choice-of-qsort-pivots problem recently
discussed on -hackers:
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php
The fact that the data contains a very large fraction of nulls
probably contributes to the problem (thanks for sending it BTW).

The reason you only see it with maintenance_work_mem >= 64M is that
below that, the problem doesn't fit into work_mem and so we don't use
qsort at all. What I still don't understand though is why you see it
in 8.1 and not 8.0 ... the src/port/qsort.c code didn't change at all
between those versions. Maybe 8.0 isn't taking the qsort code path,
perhaps because it uses a shade more memory or some such. Could you
try increasing maintenance_work_mem even more, like to 100M,
and see if 8.0 gets slow?

regards, tom lane