On 30 July 2010 00:38, Howard Rogers <hjr@diznix.com> wrote:
> I can't see any change to the sorting behaviour there. Work_mem was
> set to 4096MB, shared buffers to 12228MB, temp_buffers to 1024MB,
> effective_cache_size to 18442MB.
>
Ah yes. The sorting idea was a complete red herring. The top-N
heapsort to pick the 10 best results will never use much memory. It
looks like it all boils down to the sheer number of matches against
the search term that have to be considered in the first case. Others
on this list might have better ideas as to whether this can be
improved upon.
> Sadly, I won't be able to provide much further analysis or
> information, because the box concerned is being wiped. The MD decided
> that, as a matter of corporate governance, he couldn't punt the
> company on PostgreSQL, so my experimenting days are over. Back to
> Oracle: slower, but with a support contract he can sue on, I guess!
>
Yeah, I've been there too.
Thanks and good luck,
Dean
> Regards
> HJR
>
