Tom Lane wrote:
> Interesting. I tried your test script and got fairly close times
> for all the cases on two different machines:
> old HPUX machine: shortest 5800 msec, longest 7960 msec
> new Fedora 4 machine: shortest 461 msec, longest 608 msec
> (the HPUX machine was doing other stuff at the same time, so some
> of its variation is probably only noise).
>
> So what this looks like to me is a corner case that FreeBSD's qsort
> fails to handle well.
>
> You might try forcing Postgres to use our private copy of qsort, as we
> do on Solaris for similar reasons. (The easy way to do this by hand
> is to configure as normal, then alter the LIBOBJS setting in
> src/Makefile.global to add "qsort.o", then proceed with normal build.)
> However, I think that our private copy is descended from *BSD sources,
> so it might have the same failure mode. It'd be worth finding out.
>
>> The final interesting thing is that as I increase shared buffers to 2000
>> or 3000 the problem gets *worse*
>
> shared_buffers is unlikely to impact index build time noticeably in
> recent PG releases. maintenance_work_mem would affect it a lot, though.
> What setting were you using for that?
>
> Can anyone else try these test cases on other platforms?
>
Thanks for that.
I've since tried it on Windows (pg 8.1.2) and the times were all
similar, around 1200ms so it might just be BSD.
I'll have to wait until tomorrow to get back to my BSD box. FreeBSD
ports makes it easy to install, so I'll have to figure out how to get in
and change things manually. I guess the appropriate files are still left
around after the ports make command finishes, so I just edit the file
and make again?
If it can't be fixed though I guess we may have a problem using BSD. I'm
surprised this hasn't been brought up before, the case doesn't seem
*that* rare. Maybe not that many using FreeBSD?
I'd certainly be interested if anyone else can repro it on FreeBSD though.
Regards,
Gary.