| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| 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-21 19:00:02 |
| Message-ID: | CAH2-WzkefvVR+ZS8JEqnQHL+Lzj6bv7=i8+Lqa3wwVkkJL5koA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Nov 21, 2017 at 12:19 AM, Boris Sagadin <sagadin(at)gmail(dot)com> wrote:
> No string is over 200 chars. By function name I assumed the get_next_seq is
> pgsql related, but now I've learned it's glibc. Sorting in shell with same
> locale is indeed very slow, I used just 1% of data in that column and it
> finishes sorting in a few minutes. Thanks, I'll check with glibc.
If you upgrade to Postgres 10, you could then use ICU collations on
text columns, where CREATE INDEX can be expected to perform
significantly better:
https://blog.anayrat.info/en/2017/11/19/postgresql-10--icu--abbreviated-keys/
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jorsol | 2017-11-22 00:25:43 | BUG #14920: TEXT binding not works correctly with BPCHAR |
| Previous Message | Amit Kapila | 2017-11-21 11:52:18 | Re: 10.1: hash index size exploding on vacuum full analyze |