From: | "Timur Luchkin" <timur(dot)luchkin(at)gmail(dot)com> |
---|---|
To: | "Peter Geoghegan" <pg(at)bowt(dot)ie> |
Cc: | pgsql-bugs(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Too slow "Analyze" for the table with data in Thai language |
Date: | 2016-07-06 07:47:49 |
Message-ID: | emb351f641-830d-4ccd-a07a-e6e49a967605@luchkin-new |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello,
complete result of the perf is in the attachment.
The part with glibc looks like:
# Children Self Samples Command Shared Object
Symbol
# ........ ........ ............ .............
.......................
....................................................
59.26% 59.25% 815883 postgres libc-2.23.so
[.] __strcoll_l
--59.26%--__strcoll_l
p.s.
1. perf executed during 'long' ANALYZE as "perf record -a -g";
2. test server has 2 CPU cores
3. this is dedicated server without any parallel activity
--
Timur Luchkin
>On Tue, Jul 5, 2016 at 8:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So ... why do you think this is a Postgres bug and not a glibc bug?
>> We have no control over what happens inside strcoll().
>
>I'd be interested in seeing exactly where time is spent by glibc.
>Perhaps Timur can use perf to show us a profile using the default perf
>event type:
>
>https://wiki.postgresql.org/wiki/Profiling_with_perf
>
>--
>Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
out.txt.bz2 | application/octet-stream | 12.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Oskari Saarenmaa | 2016-07-06 10:30:57 | Re: BUG #14150: Attempted to delete invisible tuple |
Previous Message | Peter Geoghegan | 2016-07-06 06:24:13 | Re: BUG #14150: Attempted to delete invisible tuple |