Jerry Sievers <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
