Re: problem with large maintenance_work_mem settings and

On Sun, 2006-03-05 at 15:15 -0500, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> > samples  %        symbol name
> > 24915704 96.2170  ltsReleaseBlock
> > 387265    1.4955  LogicalTapeRead
> > 168725    0.6516  inlineApplySortFunction
> 
> Hmm ... the comment in ltsReleaseBlock sez
> 
>     /*
>      * Insert blocknum into array, preserving decreasing order (so that
>      * ltsGetFreeBlock returns the lowest available block number). This could
>      * get fairly slow if there were many free blocks, but we don't expect
>      * there to be very many at one time.
>      */
> 
> We probably need to tweak things so this doesn't get called during the
> "final merge" pass.  Looking at it now.

OK. I also had a report of poor performance, just isolated to the final
merge pass and sucked quite badly; sounds like you've located the cause.

Best Regards, Simon Riggs