X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 4000BDAABF for ; Fri, 11 Nov 2005 10:10:50 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 62311-02 for ; Fri, 11 Nov 2005 14:10:46 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 9E3B4DA481 for ; Fri, 11 Nov 2005 10:10:48 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jABE9bpT018037; Fri, 11 Nov 2005 09:09:37 -0500 (EST) To: Mitch Skinner cc: pgsql-performance@postgresql.org Subject: Re: same plan, add 1 condition, 1900x slower In-reply-to: <1131700635.29496.136.camel@enzian> References: <1131630176.29496.91.camel@enzian> <10164.1131643400@sss.pgh.pa.us> <1131700635.29496.136.camel@enzian> Comments: In-reply-to Mitch Skinner message dated "Fri, 11 Nov 2005 01:17:15 -0800" Date: Fri, 11 Nov 2005 09:09:36 -0500 Message-ID: <18036.1131718176@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.006 required=5 tests=[AWL=0.006] X-Spam-Score: 0.006 X-Spam-Level: X-Archive-Number: 200511/205 X-Sequence-Number: 15462 Mitch Skinner writes: > On Thu, 2005-11-10 at 12:23 -0500, Tom Lane wrote: >> Apparently, you are using a platform and/or locale in which strcoll() is >> spectacularly, god-awfully slow --- on the order of 10 msec per comparison. > The version with the condition is definitely doing more I/O. The > version without the condition doesn't read at all. That's pretty interesting, but what file(s) is it reading exactly? It could still be strcoll's fault. The only plausible explanation I can think of for strcoll being so slow is if for some reason it were re-reading the locale definition file every time, instead of setting up just once. If it is hitting Postgres files, it'd be interesting to look at exactly which files and what the distribution of seek offsets is. regards, tom lane