Hi Tom;
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Jerry Sievers <jerry@jerrysievers.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?
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/
