Re: long analyze, libc bug and libicu

On 07/07/2018 10:10 AM, Peter Eisentraut wrote:

On 05.07.18 17:05, Grigory Smolkin wrote:

Why ANALYZE igrones column COLLATE?

I think the statistics would be mostly the same independent of which
collation you use.  This could possibly be refined, but I don't think
it's a major problem right now.

Thank you for your interest in this problem!

I think the statistics would be mostly the same independent of which
collation you use.

I assumed that one of the goals of using libicu is to be independent from libc collation and it`s bugs and inconsistencies, but current ANALYZE forced to use libc anyway, which undermines that goal.

 This could possibly be refined, but I don't think
it's a major problem right now.

It`s a major problem to people, who use Thai alphabet.
In attachment there is a data sample(33MB on my machine). ANALYZE`ing it comes up with following results:

postgres=# ANALYZE t_icu_coll;
ANALYZE
Time: 2252086.648 ms

37minutes on 33MB table is painful. On big tables autovacuum ANALYZE goes for hours, starving autovacuum VACUUM for worker slots(autovacuum_max_workers).
Another major problem is that in strol_l() backend process ignores pg_terminate_backend()/pg_cancel_backend() functions.

With attached patch this problem goes away:

postgres=# analyze t_icu_coll;
ANALYZE
Time: 161.419 ms

-- 
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company