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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux