Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jL7pf-0003K8-Fc for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 16:09:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jL7pe-00066N-5q for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 16:09:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1jL7pd-00063a-SB for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2020 16:09:09 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1jL7pc-0004wg-9q for pgsql-hackers@postgresql.org; Sun, 05 Apr 2020 16:09:09 +0000 Received: by mail-wm1-x344.google.com with SMTP id r16so12177875wmg.5 for ; Sun, 05 Apr 2020 09:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dFbllQsQ2Dl45grYI2lc14Uwic+wZeH0ajLsrrN4hCs=; b=Q/2ajMCczyTziH62zAHogPKIMW43MBuVSg1z1S6ffiWLiy4LjNW5c2own1kKLwNPl1 oU6Cu9/6TNT/2/lYSqXzXPlyDxo0OMQEJclidAwNdj/MJZLvqeL97Wd5vu5t7p509jLk pGkHw/mi1inUiEYgspXEUZcpmudTFjRCIoz++2qCRPUbluCaOZi/E6yKbzcx4VzLl7U5 zQKY+sWPh+6OOxhg80PWeXbnn205f7WrBk1XCOOOX7hrlP3Xum0bO5l11F/MZ26qhrD3 yI9MUSpdcxSn+tNFEg1vmZGN81/+tcCrPl9uE1HfKC73BN5SIYkHrJVLwleiq5kub99N ov2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dFbllQsQ2Dl45grYI2lc14Uwic+wZeH0ajLsrrN4hCs=; b=Dxud+OVCrJdowahMqE/nDNXw9cFwhYMo6ksMSWYe1FW7EL1dIKVciCzlwDhXyo4+fc FjRXylMgbXD1pR7WYwMhA9wR1G06vLaMhRmzq/KEn5ZNv66uwlj5oCdvbwnaukLWoGCG GLByeURaK1Y5FIr8hDOOxD5D8X2YSumgtTWE9bVvRJlETpOafvrR7qbMl+hWJ2vd+pVf VcDOzoGBc4+FuSuQPaWTPabDTU++JGCxvEhjTKdnS+lZH0SYa3yttgYOoueHx3JskIkX sh3VQPrREyschYlMdeKQh8nFFm/VtNRHpRWyr3fKs1PLsdTjZU8nKFsbDaf9se8a0iNB DlfQ== X-Gm-Message-State: AGi0PuZE+XV374Vm063rOdcNdphL4GKJrUd1cDx+bv9I/CG2YHNE7ZZ6 3dvuzSnYAEQZHdEbmROBf4c= X-Google-Smtp-Source: APiQypJir71Al+aI5t7Mycr0JWTUW8n5yUlo9v38wP9qim/15FUuncOjc6FL54VQe43N4yLCa6iZhg== X-Received: by 2002:a1c:5541:: with SMTP id j62mr5827934wmb.155.1586102947089; Sun, 05 Apr 2020 09:09:07 -0700 (PDT) Received: from localhost (dslb-094-222-004-201.094.222.pools.vodafone-ip.de. [94.222.4.201]) by smtp.gmail.com with ESMTPSA id f3sm21651800wmj.24.2020.04.05.09.09.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 09:09:06 -0700 (PDT) Date: Sun, 5 Apr 2020 18:10:29 +0200 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Dilip Kumar Cc: David Rowley , Kyotaro Horiguchi , Tomas Vondra , florisvannee@optiver.com, Peter Geoghegan , Jesper Pedersen , Alvaro Herrera , Thomas Munro , James Coleman , Rafia Sabih , Jeff Janes , bhushan.uparkar@gmail.com, PostgreSQL-development , Alexander Korotkov Subject: Re: Index Skip Scan Message-ID: <20200405161029.fpqqll7xbgfqy5na@localhost> References: <20200308142228.3zb237cd3oedspl2@localhost> <20200309195714.eum3b6e5mogqj3gm@localhost> <20200310123942.nse4uyd6yqtb7uyi@localhost> <20200324163919.7nwqe72xzfatix4y@localhost> <20200325085100.5fixaiteuoln4f45@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote: > > I was just wondering how the distinct will work with the "skip scan" > if we have some filter? I mean every time we select the unique row > based on the prefix key and that might get rejected by an external > filter right? Not exactly. In the case of index-only scan, we skipping to the first unique position, and then use already existing functionality (_bt_readpage with stepping to the next pages) to filter out those records that do not pass the condition. There are even couple of tests in the patch for this. In case of index scan, when there are some conditions, current implementation do not consider skipping. > So I tried an example to check this. Can you tell on which version of the patch you were testing?