Hi Tom; Tom Lane <tgl@xxxxxxxxxxxxx> writes: > Jerry Sievers <jerry@xxxxxxxxxxxxxxxx> 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? I did as you suggest here; taking the MWM setting incrementally up to nearly a Gig in 100M increments, also raised and lowered the work_mem setting too. Tried a dozen or more combos and in every case, the index built quickly on 8.0.3. Very interesting! Thanks for all your help. -- ------------------------------------------------------------------------------- Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant 305 321-1144 (mobile http://www.JerrySievers.com/
