X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id A90FD9DC803 for ; Wed, 15 Feb 2006 17:36:14 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 26110-04 for ; Wed, 15 Feb 2006 17:36:16 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from server.gpdnet.co.uk (gpdnet.plus.com [212.56.100.243]) by postgresql.org (Postfix) with ESMTP id 5F1959DC843 for ; Wed, 15 Feb 2006 17:36:12 -0400 (AST) Received: from [192.168.1.2] (unknown [192.168.1.2]) by server.gpdnet.co.uk (Postfix) with ESMTP id D0FC33AAB28; Wed, 15 Feb 2006 21:46:53 +0000 (GMT) Message-ID: <43F39E53.1020009@gpdnet.co.uk> Date: Wed, 15 Feb 2006 21:34:11 +0000 From: Gary Doades User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org Subject: Re: Strange Create Index behaviour References: <43F38867.6010701@gpdnet.co.uk> <19510.1140036968@sss.pgh.pa.us> <19779.1140038874@sss.pgh.pa.us> In-Reply-To: <19779.1140038874@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200602/220 X-Sequence-Number: 17206 Tom Lane wrote: > I tried forcing PG to use src/port/qsort.c on the Fedora machine, > and lo and behold: > new Fedora 4 machine: shortest 434 msec, longest 8530 msec > > So it sure looks like this script does expose a problem on BSD-derived > qsorts. Curiously, the case that's much the worst for me is the third > in the script, while the shortest time is the first case, which was slow > for Gary. So I'd venture that the *BSD code has been tweaked somewhere > along the way, in a manner that moves the problem around without really > fixing it. (Anyone want to compare the actual FreeBSD source to what > we have?) > If I run the script again, it is not always the first case that is slow, it varies from run to run, which is why I repeated it quite a few times for the test. Interestingly, if I don't delete the table after a run, but just drop and re-create the index repeatedly it stays a pretty consistent time, either repeatedly good or repeatedly bad! Regards, Gary.