Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qp893-004TeA-6Q for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Oct 2023 14:19:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qp890-00HSiF-OM for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Oct 2023 14:19:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qp890-00HShr-F0 for pgsql-bugs@lists.postgresql.org; Sat, 07 Oct 2023 14:19:03 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qp88z-000mFm-5K for pgsql-bugs@lists.postgresql.org; Sat, 07 Oct 2023 14:19:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 397EIuFq3123966; Sat, 7 Oct 2023 10:18:56 -0400 From: Tom Lane To: Laurenz Albe cc: pperalta@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18149: Incorrect lexeme for english token "proxy" In-reply-to: <25d0bf34e0f7e0d9f3455e1b7adaf5a5aee810e1.camel@cybertec.at> References: <18149-936d14e6fc76ca61@postgresql.org> <25d0bf34e0f7e0d9f3455e1b7adaf5a5aee810e1.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Sat, 07 Oct 2023 14:49:21 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3123964.1696688336.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 07 Oct 2023 10:18:56 -0400 Message-ID: <3123965.1696688336@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laurenz Albe writes: > On Thu, 2023-10-05 at 21:44 +0000, PG Bug reporting form wrote: >> The english dictionary is using the lexeme "proxi" for the token "proxy= ". As >> a result, the search term "proxy" is not yielding results for records t= hat >> contain this word. > I cannot reproduce that. Me either. It suggests that you're trying to match against documents that haven't been put through the same normalization process as the query. >> I think this lexeme was chosen to support the plural of proxy which is >> proxies. However there are other plurals where the root word is spelled >> different and Postgres creates the correct lexeme such as: [goose or mo= use] > The snowball dictionary has no real knowledge of the words. Stemming is > done by applying some heuristics which work "well enough" in most cases. Yeah. I don't see anything hugely wrong with this particular transformation. It is doing something useful, in that "proxy" and "proxies" are both converted to the same lexeme "proxi". In an ideal world, the lexeme would be "proxy", but it doesn't really make that much difference if it isn't. In any case, changing it now wouldn't be very practical, because existing documents will already have been made into tsvectors using this rule. regards, tom lane