Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNcVA-000390-0X for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 16:31:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNcV6-0002DS-Et for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 16:31:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNcV6-0002DJ-1f for pgsql-hackers@lists.postgresql.org; Thu, 02 Feb 2023 16:31:52 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pNcV2-0007yq-Ud for pgsql-hackers@postgresql.org; Thu, 02 Feb 2023 16:31:51 +0000 Received: by mail-ej1-x629.google.com with SMTP id qw12so7609820ejc.2 for ; Thu, 02 Feb 2023 08:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=0IIUPJHrD6YLJhdKWcJjzaQ2z4PHZIwJqQFlNX9hFgE=; b=0tJTirCpkrHcsgLOXna1A2ADs+2EEbppAtkWHxQklG2tYRfPy/WUM2WULJyBaPjSjF TmHeQoDOM17koYzqptBaS4qHfnHWyPjx7s3KNJbD37besnDwBBWDhRG+DEzNeLTSZfIU N1sCe3hYr1/v5P8KMP5dK3fcOwcJ1AqbW4yaqBLw8pCSjC7zXXcPcdj4jrcs94RjyVe6 yt+LR1q1a1WCcMCZqhRaImr54QD2NNsoz9G1K8lIwIMGmoDksJR/nB8ViIr7z651BUbf L9Hgj669+JeBIOuMB4GDhZ7SLz6R5V7wokDwBrPGAt3H3qgSmBFYcVILmNH0OwvpMnw6 Vy2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0IIUPJHrD6YLJhdKWcJjzaQ2z4PHZIwJqQFlNX9hFgE=; b=eg5Oyc2r/aiLCN5KctbYyD+UNyuBZsrfjIfopFgrxQ8DrNOe63p2mSMrVcoRFWDz7l nJS0Z628EK7PI67XfxBEQqV0BkZwTkqe3LOr8WuffJDdxzEAY8xlovxIHnYvuh7AZe+n HX4rNGiteAHIjMstJarFVZGAQ/WXEEU3aCjOSNrcURZxbLHv+EDAmZrRKYV2YaAbuXUu cwIROYvPJfhDY/pfuWDg7wEsKOzklBGelIH9XSBhd9VpS9eIZaCXCT8MScCKSDHeM00V r3hosIVjydE0OJ4gZJw1roLiYLvO0IWTAv7ECto1McMTWR9VupnY7oPZMGHVxOw9VUDv HJjA== X-Gm-Message-State: AO0yUKUZy1PplQ6jGFxMizWtkQNRy2pZ3uvRlqthR4+gQoqOiUs28ipW gunTyTeMbQ2sVSbdJrO9pr/5TiIjVGURRXQs X-Google-Smtp-Source: AK7set8Tg+V4HHtnsu5jk+N0H5rKc9aBHm7QS7SrwpQfGGLLeuycETgdicDkv9r+oA/ASmG82dnB0A== X-Received: by 2002:a17:906:cc5a:b0:88c:f8a1:fc4a with SMTP id mm26-20020a170906cc5a00b0088cf8a1fc4amr6314360ejb.9.1675355507922; Thu, 02 Feb 2023 08:31:47 -0800 (PST) Received: from [172.22.33.132] (67.224-78-194.adsl-static.isp.belgacom.be. [194.78.224.67]) by smtp.gmail.com with ESMTPSA id ke1-20020a17090798e100b00877f2b842fasm8385ejc.67.2023.02.02.08.31.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 08:31:47 -0800 (PST) Message-ID: Subject: Re: Move defaults toward ICU in 16? From: Jeff Davis To: Robert Haas Cc: pgsql-hackers@postgresql.org Date: Thu, 02 Feb 2023 08:31:46 -0800 In-Reply-To: References: <510d284759f6e943ce15096167760b2edcb2e700.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2023-02-02 at 08:44 -0500, Robert Haas wrote: > On Thu, Feb 2, 2023 at 8:13 AM Jeff Davis wrote: > > If we don't want to nudge users toward ICU, is it because we are > > waiting for something, or is there a lack of consensus that ICU is > > actually better? >=20 > Do you think it's better? Yes: * ICU more featureful: e.g. supports case-insensitive collations (the citext docs suggest looking at ICU instead). * It's faster: a simple non-contrived sort is something like 70% faster[1] than one using glibc. * It can provide consistent semantics across platforms. I believe the above reasons are enough to call ICU "better", but it also seems like a better path for addressing/mitigating collator versioning problems: * Easier for users to control what library version is available on their system. We can also ask packagers to keep some old versions of ICU available for an extended period of time. * If one of the ICU multilib patches makes it in, it will be easier for users to select which of the library versions Postgres will use. * Reports versions for indiividual collators, distinct from the library version. The biggest disadvantage (rather, the flip side of its advantages) is that it's a separate dependency. Will ICU still be maintained in 10 years or will we end up stuck maintaining it ourselves? Then again, we've already been shipping it, so I don't know if we can avoid that problem entirely now even if we wanted to. I don't mean that ICU solves all of our problems -- far from it. But you asked if I think it's better, and my answer is yes. Regards, Jeff Davis [1] https://postgr.es/m/64039a2dbcba6f42ed2f32bb5f0371870a70afda.camel@j-davis.= com