Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCSMN-0003Ro-Bs for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Nov 2017 15:33:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eCSMM-00064j-TS for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Nov 2017 15:33:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eCSML-0005ze-Mf for pgsql-hackers@postgresql.org; Wed, 08 Nov 2017 15:33:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eCSMH-0002TI-Rw for pgsql-hackers@postgresql.org; Wed, 08 Nov 2017 15:33:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vA8FXJ9n019571; Wed, 8 Nov 2017 10:33:19 -0500 From: Tom Lane To: Robert Haas cc: Andres Freund , Claudio Freire , =?UTF-8?B?0K7RgNC40Lkg0KHQvtC60L7Qu9C+0LI=?= , Sokolov Yura , Alvaro Herrera , Heikki Linnakangas , PostgreSQL-Dev Subject: Re: Small improvement to compactify_tuples In-reply-to: References: <20171107152004.axgznk3n5tkzvnnt@alap3.anarazel.de> <29007.1510090796@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 08 Nov 2017 06:13:53 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19569.1510155199.1@sss.pgh.pa.us> Date: Wed, 08 Nov 2017 10:33:19 -0500 Message-ID: <19570.1510155199@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote: >> What I'm getting from the standard pgbench measurements, on both machines, >> is that this patch might be a couple percent slower than HEAD, but that is >> barely above the noise floor so I'm not too sure about it. > Hmm. It seems like slowing down single client performance by a couple > of percent is something that we really don't want to do. I do not think there is any change here that can be proven to always be a win. Certainly the original patch, which proposes to replace an O(n log n) sort algorithm with an O(n^2) one, should not be thought to be that. The question to focus on is what's the average case, and I'm not sure how to decide what the average case is. But more than two test scenarios would be a good start. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers