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 1iuNgG-0002hh-Jb for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2020 21:36:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iuNgF-0000u6-EV for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2020 21:36:55 +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 <9erthalion6@gmail.com>) id 1iuNgF-0000tz-5Z for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2020 21:36:55 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1iuNgD-000389-55 for pgsql-hackers@postgresql.org; Wed, 22 Jan 2020 21:36:54 +0000 Received: by mail-wr1-x443.google.com with SMTP id g17so749849wro.2 for ; Wed, 22 Jan 2020 13:36:53 -0800 (PST) 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=1+Mv7B5m9ue7x+5APCCwLlkd0xlxzjm9tc2HoQMyIH0=; b=uU4Aave2G+M3a3+/78LqzkpiKK6a8qOTMB4eboxyHKyd+yFokHpg+5KBOEncaGSEZ7 6of4bH+NBv2OkDHAO6I9wDtS+eNINf+uMHStKoJCWcwzttyBp7szquUxTikzyzFGagXg q+Crvvl5xZ6eQ1Z+/4yJl5TG/QeD/SplPXeccklDtLxY9p9YlyXQX9HS1KW42ra/tbva NDn/Vzbt1dE9VmmsLo6+zjDpXo/ZMcYsO5iNUxfvXb0naluIJAv8sj2BwflzYZi4Utef SwqBzwNEoidKugNXuApaItEqBe5cQRpAs+QpVctIlWGIzkakVNw7SDVYWuvjO/uYiofC JeXA== 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=1+Mv7B5m9ue7x+5APCCwLlkd0xlxzjm9tc2HoQMyIH0=; b=d03lfSRXy3EFXpPtl14Rg3oXVjy5xLEqaaeHMEK1HrLhEXnRCoovQVGJCTaqt+wXGZ iXyyzTvrFAM92zPFBnVm9NJHyT96th/tZ93vbDFgfFu8dHTXu8VPUPXuMi/wzN7BeBj4 5nq5x+PFkV/Rc8a1RqKkLmdO01AiyAcBEkqavDcHm5Esim9vmpbg9bfNsE3K45I35aWz rLDUT/B2LVrUxYulfnFsCAqrZ1F1XhdJHWV85HwGD2Zpx/oFcWZVPzhgLRKGv2S0xFnd v35AtG4C+5TstUROsNto7XfISkNW2FPefPWKRIXV4fhvRJsOFHvjlqxbIWKWv/SqMRp3 QenA== X-Gm-Message-State: APjAAAXZ67ooxN930XsYKPS4EWCjCZdnYoiOt1rLuCBZwIMx0KgWvpQb zsxSlBE4SkTu5mVpqxrUnnu2FHS9MbIPdw== X-Google-Smtp-Source: APXvYqxFBRZ/nXSCaVxwVaqB03UXR8/pEm7iA48fVsZTaLbxZYP4PTKvRYEbDwo+313nbNo/9XHzrw== X-Received: by 2002:adf:dd46:: with SMTP id u6mr12888012wrm.13.1579729012322; Wed, 22 Jan 2020 13:36:52 -0800 (PST) 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 g7sm147910wrq.21.2020.01.22.13.36.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 13:36:51 -0800 (PST) Date: Wed, 22 Jan 2020 22:37:16 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Floris Van Nee Cc: Peter Geoghegan , Jesper Pedersen , David Rowley , Tomas Vondra , Kyotaro Horiguchi , Alvaro Herrera , Thomas Munro , James Coleman , Rafia Sabih , Jeff Janes , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov Subject: Re: Index Skip Scan Message-ID: <20200122213716.ghvobtxsrfncjyye@localhost> References: <1e59d800b38141c5af2ad3a64cf9758e@opammb0562.comp.optiver.com> <802e46fa-dc2c-4c32-e55b-884e04aa7f12@redhat.com> <20200121160942.eu4bvbu46nt223ug@localhost> <105fd98b36dc4c0cb6b3dc41106b5556@opammb0562.comp.optiver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <105fd98b36dc4c0cb6b3dc41106b5556@opammb0562.comp.optiver.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Wed, Jan 22, 2020 at 09:08:59PM +0000, Floris Van Nee wrote: > > Note in particular that index scans cannot return the same index tuple twice - > > - processing a page at a time ensures that that cannot happen. > > > > Can a loose index scan return the same tuple (i.e. a tuple with the same heap > > TID) to the executor more than once? > > > > The loose index scan shouldn't return a tuple twice. It should only be able to skip 'further', so that shouldn't be a problem. Yes, it shouldn't happen.