| From: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
|---|---|
| To: | István <leccine(at)gmail(dot)com> |
| Cc: | PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Weird CPU utilization patterns with Postgres |
| Date: | 2014-12-10 01:46:06 |
| Message-ID: | CAEYLb_VbVmRjMB6ruuE64pARkY_ASKxZCVQnWuUHE5D-jhrOdA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Dec 5, 2014 at 5:14 PM, István <leccine(at)gmail(dot)com> wrote:
> I am wondering why the root cause might be here.
My guess would be that an important text-based sort operation began to
go to disk. The external sort code (tapesort) is known to do far more
comparisons than quicksort. With text sorts, you tend to see tapesort
very CPU bound, where that might not be the case with integer sorts.
I'm currently trying to fix this across the board [1], but my first
suggestion is to try enabling log_temp_files to see if external sorts
can be correlated with these stalls.
[1] https://commitfest.postgresql.org/action/patch_view?id=1462
--
Regards,
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2014-12-10 02:06:13 | Re: Weird CPU utilization patterns with Postgres |
| Previous Message | AJ Welch | 2014-12-10 01:21:10 | Re: Use cases for lateral that do not involve a set returning function |