Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxF54-0001Or-L9 for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 15:16:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bxF54-00012i-8a for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 15:16:30 +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 1bxF3e-0005UK-TZ for pgsql-hackers@postgresql.org; Thu, 20 Oct 2016 15:15:03 +0000 Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bxF3b-00082R-Vv for pgsql-hackers@postgresql.org; Thu, 20 Oct 2016 15:15:01 +0000 Received: by mail-lf0-x22f.google.com with SMTP id b75so86656104lfg.3 for ; Thu, 20 Oct 2016 08:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=u++oP4QY8tfZc4LqKNDFlwZ4Ay6rmEhdmv0f1bUR/Qc=; b=ZftxlG4k9+JoeuL9xDdtavW6Fk20/Mik8kz3IUrUiHF53fNAEjk2qAkio3wnJ9vbJI QlEvXvmWCSgAPXOmQp8Dc/WzwjCgmvOyz2OuTLy3sTejFxMt/YqelhIL9spFCQllEJQ4 i5AAZz3bHVLoKjm6t8Bhjjw6/5NA9zDqtWnTgQsfm01g7bg0hJv9Uw/rz7kHAHplsOQs pg14GFpD9ML5PlgoVvfImKWKz9mYlE9VCzuCMW+VgEJ/PQsgP3Y++X363cdW56pKO7d2 vcvChScx11nmFi00uEd6HN2Q3n8BSyfvOBxrF+Eup3e7MC6USinLlX7kiPVYdUMhdxZT cZ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=u++oP4QY8tfZc4LqKNDFlwZ4Ay6rmEhdmv0f1bUR/Qc=; b=X1Lenr6ExY4UsiZArVgHE2rJlA3rtt9YIrzjH+wXA3WpJueyuR3p5niSIgXkoBZPv0 nqxaZ6qqKCr8+WQBk2zMabxTM5j/8TPokkPpWM26UFQqZY8o9oR/4lytF6vqJLoJrJ8x wwHlahnzmg6t+ZPyPClXAwDNT7iQEpVUN0jRgk+mY0YuSPqFCs2Ozn0RD0tUoFlAhPY1 ugpEVC0gD4xVW+QIxUbNPatW7IQb0jg9icCVXSk7bBYkz2dRDeitnAE/sMB3bGpUAQx1 ru+DqeyfYBEniFwUREuVaoNCwIvunCTwYnNV/2wMVhHT9D/xFebI1WsUAYJkT1gjPkXI uE7Q== X-Gm-Message-State: AA6/9RmEtQwPCJOVjd+gXkMqlGn1o+JiNdUB1FvmKQJWi7/l70myHSNpE31hXZnvJKuogJ8yUkcPSWXpQavCa7OvF0wJjd/DLnnuY9LR4hPpz+aru4mgbKgy+RucNJcdIq8AFd8zpApm5ar25XptZQSsDU1Jqq50J8L/PAiNgI1xu0LTljLNJ4pwFE04Ht2l5w== X-Received: by 10.25.190.71 with SMTP id o68mr2368472lff.23.1476976495262; Thu, 20 Oct 2016 08:14:55 -0700 (PDT) Received: from [192.168.0.105] (150.123.broadband11.iol.cz. [90.178.123.150]) by smtp.gmail.com with ESMTPSA id u10sm6048518lff.37.2016.10.20.08.14.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 08:14:53 -0700 (PDT) Subject: Re: Indirect indexes To: Bruce Momjian , Simon Riggs References: <20161018182843.xczrxsa2yd47pnru@alvherre.pgsql> <20161019164043.GN5087@momjian.us> <20161019170416.GR5087@momjian.us> <20161020122937.GA28621@momjian.us> Cc: Pavan Deolasee , Alexander Korotkov , Robert Haas , Alvaro Herrera , Pg Hackers From: Petr Jelinek Message-ID: <13500012-c20a-1fc4-5a57-054c9aeb4e25@2ndquadrant.com> Date: Thu, 20 Oct 2016 17:14:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161020122937.GA28621@momjian.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.6 (--) 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 On 20/10/16 14:29, Bruce Momjian wrote: > On Wed, Oct 19, 2016 at 01:04:16PM -0400, Bruce Momjian wrote: >> On Wed, Oct 19, 2016 at 06:58:05PM +0200, Simon Riggs wrote: >>>>> I agree. Also, I think the recheck mechanism will have to be something like >>>>> what I wrote for WARM i.e. only checking for index quals won't be enough and we >>>>> would actually need to verify that the heap tuple satisfies the key in the >>>>> indirect index. >>>> >>>> I personally would like to see how far we get with WARM before adding >>>> this feature that requires a DBA to evaluate and enable it. >>> >>> Assuming WARM is accepted, that *might* be fine. >> >> First, I love WARM because everyone gets the benefits by default. For >> example, a feature that improves performance by 10% but is only used by >> 1% of users has a usefulness of 0.1% --- at least that is how I think of >> it. > > Just to clarify, if a feature improves performance by 1%, but is enabled > by default, that is 10x more useful across our entire user base as the > feature numbers listed above, 1% vs 0.1%. > > Also, it seems indirect indexes would be useful for indexing columns > that are not updated frequently on tables that are updated frequently, > and whose primary key is not updated frequently. That's quite a logic > problem for users to understand. > Which covers like 99.9% of problematic cases I see on daily basis. And by that logic we should not have indexes at all, they are not automatically created and user needs to think about if they need them or not. Also helping user who does not have performance problem by 1% is very different from helping user who has performance problem by 50% even if she needs to think about the solution a bit. WARM can do WARM update 50% of time, indirect index can do HOT update 100% of time (provided the column is not changed), I don't see why we could not have both solutions. That all being said, it would be interesting to hear Álvaro's thoughts about which use-cases he expects indirect indexes to work better than WARM. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers