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

Hi Tom;

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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?

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/