Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hbpra-0003iy-QY for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Jun 2019 17:19:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hbprY-0007LG-Kr for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Jun 2019 17:19:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hbprY-0007L9-CC for pgsql-hackers@lists.postgresql.org; Fri, 14 Jun 2019 17:19:40 +0000 Received: from mail-qt1-f175.google.com ([209.85.160.175]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hbprU-0005KS-GZ for pgsql-hackers@postgresql.org; Fri, 14 Jun 2019 17:19:39 +0000 Received: by mail-qt1-f175.google.com with SMTP id j19so3300362qtr.12 for ; Fri, 14 Jun 2019 10:19:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Eh6mrkStujOEAxIiGe4g2nMNqsHk47SqzUaSu2Jrzk0=; b=dcJdNdejHfdjzNm/TcF2DOHsPmM0r99BBoFZytp3yiPLp8YcxrwvfAjV0Jtq8geB52 GPgTrQtH6BDbA91QEBAWkyeL5ZIEZqC7Ff89M3Xn68TXQdyRIYyFOeeY5QqajRa+cYaq oGx0p3qibWBk50oAHtRTFJ4K9Qj2DgInMnp6VrUGtLgMhSsGcHhAr6PX/jP9ftYSAwBv FYDpdet+dzns34mE9adzZfO5DoEXcswZngGh57oLNd5/hNyJZQAcpWTQC4hbGpq19WoJ S0L5HS/JcsIebVmT6pgc15/10KFHNKS7znTChKpwMsLzTbIUT3rnm9rX2KeH44CdZkFK WeTA== X-Gm-Message-State: APjAAAVElBIeO1L9qdpQMKOmMsZB7iW7EyedWIXDT3JSVMXKxCo6b0IM 9G4On5R7MEDaCa0aCBgGVIM7kw== X-Google-Smtp-Source: APXvYqzzX0OPOl5oMHrGIvPp1YAlU3q5yLTcbeNR/zZv3IirEofKlC0zArrB8u9YkxaMy6zsNkcLng== X-Received: by 2002:ac8:18fa:: with SMTP id o55mr23297844qtk.275.1560532774025; Fri, 14 Jun 2019 10:19:34 -0700 (PDT) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id u7sm1729339qkh.61.2019.06.14.10.19.32 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jun 2019 10:19:33 -0700 (PDT) Reply-To: jesper.pedersen@redhat.com Subject: Re: Index Skip Scan To: James Coleman Cc: Floris Van Nee , Dmitry Dolgov <9erthalion6@gmail.com>, Rafia Sabih , Jeff Janes , Thomas Munro , Alexander Kuzmenkov , Peter Geoghegan , Tomas Vondra , Thomas Munro , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov References: <2685f020-f302-9bf6-1b5c-ebc2bcebc635@2ndquadrant.com> <20190315.125452.252656146.horiguchi.kyotaro@lab.ntt.co.jp> <1559361698401.22864@Optiver.com> <1559362223126.18661@Optiver.com> <988b7763-5c55-1be1-b7b6-f3a68eff0d40@redhat.com> <1559763453006.85615@Optiver.com> <1559763570329.85227@Optiver.com> <4d469bf2-49ff-bc3d-a428-6c7b5d87d526@redhat.com> From: Jesper Pedersen Organization: Red Hat Message-ID: <3e72646c-cbeb-be43-8f6c-aa7543131e8e@redhat.com> Date: Fri, 14 Jun 2019 13:19:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi James, On 6/13/19 11:40 PM, James Coleman wrote: > I've previously noted upthread (along with several others), that I > don't see a good reason to limit this new capability to index only > scans. In addition to the reasons upthread, this also prevents using > the new feature on physical replicas since index only scans require > visibility map (IIRC) information that isn't safe to make assumptions > about on a replica. > > That being said, it strikes me that this likely indicates an existing > architecture issue. I was discussing the problem at PGCon with Andres > and Heiki with respect to an index scan variation I've been working on > myself. In short, it's not clear to me why we want index only scans > and index scans to be entirely separate nodes, rather than optional > variations within a broader index scan node. The problem becomes even > more clear as we continue to add additional variants that lie on > different axis, since we end up with an ever multiplying number of > combinations. > > In that discussion no one could remember why it'd been done that way, > but I'm planning to try to find the relevant threads in the archives > to see if there's anything in particular blocking combining them. > > I generally dislike gating improvements like this on seemingly > tangentially related refactors, but I will make the observation that > adding the skip scan on top of such a refactored index scan node would > make this a much more obvious and complete win. > Thanks for your feedback ! > As I noted to Jesper at PGCon I'm happy to review the code in detail > also, but likely won't get to it until later this week or next week at > the earliest. > > Jesper: Is there anything still on your list of things to change about > the patch? Or would now be a good time to look hard at the code? > It would be valuable to have test cases for your use-cases which works now, or should work. I revived Thomas' patch because it covered our use-cases and saw it as a much needed feature. Thanks again ! Best regards, Jesper