From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boris Sagadin <sagadin(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14917: process hang on create index |
Date: | 2017-11-20 17:55:18 |
Message-ID: | 17458.1511200518@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Boris Sagadin <sagadin(at)gmail(dot)com> writes:
> Thanks Tom, I made a few traces on the process, one at the beginning and a
> few later when it seems stuck, below is the output.
Well, it looks to me like it's not hung, it's just busy sorting.
It is making progress, since the successive traces show different
values being compared.
97% of the runtime in strcoll() is a bit weird. strcoll() is known
to be unpleasantly slow in some locales, but that seems excessive.
Perhaps you've discovered a performance bug in strcoll() for certain
input data. That wouldn't be our problem though --- you'd need to
complain to the glibc maintainers.
It'd be interesting to dump out the data in that column into a text file
and see if sorting that with sort(1) (in the same locale!) is equally
slow. If it is, that would confirm the assignment of blame to strcoll().
But the glibc folk would want to see sample data too, so one way or
another you're going to need to sanitize that data enough to show
it to somebody else.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-11-20 18:17:08 | Re: BUG #14917: process hang on create index |
Previous Message | Marko Tiikkaja | 2017-11-20 14:16:20 | Re: BUG #14919: Invalid column in sub select is still a valid select |