Date: Sat, 7 Jul 2018 10:16:48 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Grigory Smolkin <g.smolkin@postgrespro.ru>
Cc: pgsql-bugs@lists.postgresql.org,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Subject: Re: long analyze, libc bug and libicu
Message-ID: <20180707141648.GN27724@tamriel.snowman.net>
References: <dc49b0d2-d20d-adeb-ecdb-0ad25461386d@postgrespro.ru>
 <ca8fc598-da02-d987-4e5c-8c249df9de40@2ndquadrant.com>
 <2da0c289-bfc8-a40f-e13b-1b2943746e9e@postgrespro.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Xbm1c71Mb9oMDm4h"
Content-Disposition: inline
In-Reply-To: <2da0c289-bfc8-a40f-e13b-1b2943746e9e@postgrespro.ru>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--Xbm1c71Mb9oMDm4h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Grigory Smolkin (g.smolkin@postgrespro.ru) wrote:
> 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.
>=20
> Thank you for your interest in this problem!
>
> >I think the statistics would be mostly the same independent of which
> >collation you use.
>=20
> 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 for=
ced
> to use libc anyway, which undermines that goal.

I would have thought so too, especially in a case like you describe
below...

> >  This could possibly be refined, but I don't think
> >it's a major problem right now.
>=20
> 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:
>=20
> postgres=3D# ANALYZE t_icu_coll;
> ANALYZE
> Time: 2252086.648 ms
>=20
> 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.
>=20
> With attached patch this problem goes away:
>=20
> postgres=3D# analyze t_icu_coll;
> ANALYZE
> Time: 161.419 ms

Wow, that's definitely an issue.

I haven't looked at the patch in any depth, but definitely a +1 from me
for figuring out how to fix this issue..

Thanks!

Stephen

--Xbm1c71Mb9oMDm4h
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJbQMtPAAoJEO1sijiDR2RV8fkP/izYMXhHpwvC55blnYpoHmMb
/6SdvJTNhcSfZYrj21SODVQ+h+CQ64Puaw2SUL/Aos9TTVr841gqFEz5QPuNEgHv
SykJ5TeATWZcZ+fQa0d0v7Mxn38UZUlH3MP7PV6FyTfNXtb0GWs+Ad1vqtZgqkDZ
wf2xyW3bQd08yvNhoqyYRw2Ek7TT9P2NqwrfhXN82CyF2EJmgYHOcZYHcT2CmiKK
HPcjW2QFDTkB3UBI2WFwI/GsNBukZ6pRnt46/JbS/1jVnSbdtml6qXIHD1iKcI3v
5NVxXZusM+i8GWuiIz+vq5b9IAI59ByV0GNyBk5l0+eR+YSJUqbuWE4mqQ5EDltS
JSJmcs+lTeKBZl8jBXkh3+IfAxlHId9Tvu3TCDP2fqGYotyzr1ig7/dqOhPCbcuX
CL9p8yB7EjYhs5/YKqkuqtFS/NIWEKSHlqVZuRu/8pAZABajgdi6Wqu+h5pthCEW
XcJKc3HG+Y/qWWo2tJmTgvAXm+R6DaWvXRGawrmALv6GWw9Qnfy/X4KDIPb8Lgat
jF2e+tqotSscUl+Fa9+AEZp81BPcLpx6nZJTS2HWLGTh2dp1mKd/F0e6zDfhuBra
JX/QXxim7xT8up39eQI5ndQcS2/rf5qZw4ZYN6rh5sIQi6Rv+cVNmNupb1TXFWPY
CImeckzpXUD6Uoqvf0QS
=rj3i
-----END PGP SIGNATURE-----

--Xbm1c71Mb9oMDm4h--