X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 66C9B9DCCC8 for ; Thu, 16 Feb 2006 12:20:28 -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 28596-02 for ; Thu, 16 Feb 2006 12:20:26 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 2A1CD9DCC71 for ; Thu, 16 Feb 2006 12:20:26 -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 k1GGKNap028769; Thu, 16 Feb 2006 11:20:23 -0500 (EST) To: Ron cc: Martijn van Oosterhout , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: qsort again (was Re: [PERFORM] Strange Create In-reply-to: <7.0.1.0.2.20060216100954.035b5ee0@earthlink.net> References: <43F38867.6010701@gpdnet.co.uk> <19510.1140036968@sss.pgh.pa.us> <19779.1140038874@sss.pgh.pa.us> <43F39E53.1020009@gpdnet.co.uk> <20781.1140046109@sss.pgh.pa.us> <7.0.1.0.2.20060215194635.03b55da0@earthlink.net> <21615.1140052893@sss.pgh.pa.us> <7.0.1.0.2.20060215223710.03a7c618@earthlink.net> <20060216113522.GA3461@uio.no> <7.0.1.0.2.20060216071053.0385a1a8@earthlink.net> <20060216144833.GG26127@svana.org> <7.0.1.0.2.20060216100954.035b5ee0@earthlink.net> Comments: In-reply-to Ron message dated "Thu, 16 Feb 2006 10:52:48 -0500" Date: Thu, 16 Feb 2006 11:20:23 -0500 Message-ID: <28768.1140106823@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.11 required=5 tests=[AWL=0.110] X-Spam-Score: 0.11 X-Spam-Level: X-Archive-Number: 200602/628 X-Sequence-Number: 79766 Ron writes: > Your cost comment basically agrees with mine regarding the cost of > random memory accesses. The good news is that the number of datums > to be examined during the pivot choosing process is small enough that > the datums can fit into CPU cache while the pointers to them can be > assigned to registers: making pivot choosing +very+ fast when done correctly. This is more or less irrelevant given that comparing the pointers is not the operation we need to do. regards, tom lane