| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Michael Paesold <mpaesold(at)gmx(dot)at>, hubert depesz lubaczewski <depesz(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: problem with large maintenance_work_mem settings and |
| Date: | 2006-03-06 06:36:31 |
| Message-ID: | 1141626991.27729.632.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2006-03-05 at 15:15 -0500, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2006-03-06 07:07:34 | Re: Uninstall script errors |
| Previous Message | Ben Chelf | 2006-03-06 05:35:45 | Coverity Open Source Defect Scan of PostgreSQL |