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 1juICr-0005rM-4E for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Jul 2020 16:18:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1juICq-00025r-2P for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Jul 2020 16:18:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1juICp-00025j-NV for pgsql-hackers@lists.postgresql.org; Sat, 11 Jul 2020 16:18:27 +0000 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1juICn-0005G4-J3 for pgsql-hackers@postgresql.org; Sat, 11 Jul 2020 16:18:26 +0000 Received: by mail-ej1-x643.google.com with SMTP id w6so9451209ejq.6 for ; Sat, 11 Jul 2020 09:18:25 -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=r/6ayTkPN1BFMSdu+wc0jBdEbjJ2l1Zf7Vvmj0Cdm64=; b=Szfkvz4qa0ADJHvc3huEDwNkaq2j6NtcIreuWYVfX0HnufaLOaMYPjQXQLvOsMqVJJ 1CICxOfTLvDPhwO2zS6i8YlPqS44kDB4WNfpCHqulhAWJRW7SGKmEkVJZcJuyj/2WxaI 7Lh4hgA67m90f++GXNPWpk1Y9h/mnElC/fsrE59OfrPX2WfUTyIfYLsPMuG9578KJDrz c12YGKXspEZ63CfWtEbWKzyErEo0mJb2wwodOUbVbkNj4zIcDF1HffyWO9o4gk4kT20E SDXA7Vn7HCHSzuFxh4+xOJ/jMdgIvFxzssbskpltI1pdx1NIN5s10nkveFQWqUcsNO1L ZmmQ== 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=r/6ayTkPN1BFMSdu+wc0jBdEbjJ2l1Zf7Vvmj0Cdm64=; b=HjrL7T6kjmNtotHEO8YhP4OUyzWmP5EhvT1ZVqA0g+sXvGFM0L0IHNBIbe4NRalum8 zVCySyC4lqPdntvXDJSw6fsePzpidSXpPLjA0NkYpfot1ufoha0B2nAXaNAwV7UKfx5W QQJEPcW4Hd+yudzi9AcAOMfWxRlIz6arOISyOqy1qhyRKZuUPbrEJ6CPgDPRfsX0iGn+ gPyWHrygRogfWQl00xwhIM+e003KrPNa7tYTzFgGBQtjzJGG4jKpRt8vebqmXM/a8GxX Op3IzTQad7GTkU0F1J7TZPPfQ/AZtdVQx8L7oRq6hH5sipRRpCy7HUPPjQMG3Yb4UchB tG4g== X-Gm-Message-State: AOAM530NgmTVPOyRRj7N4l1qD1Va4w5IwFHRID/K57zrC8FJZK0i9oey Lel5aPiRYFnJWcG/qbCS+W0= X-Google-Smtp-Source: ABdhPJxM8fMWVchherpQxaIk+XPWRH6HveWLKgRMur+m4RaHTVhtrdQ4YyndY1Z3uzzUe7PNoAmbeA== X-Received: by 2002:a17:906:7247:: with SMTP id n7mr66372028ejk.105.1594484304127; Sat, 11 Jul 2020 09:18:24 -0700 (PDT) Received: from localhost (dslb-178-005-232-008.178.005.pools.vodafone-ip.de. [178.5.232.8]) by smtp.gmail.com with ESMTPSA id y22sm7059211edl.84.2020.07.11.09.18.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jul 2020 09:18:23 -0700 (PDT) Date: Sat, 11 Jul 2020 18:21:03 +0200 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Floris Van Nee Cc: Andy Fan , PostgreSQL-development , Jesper Pedersen , David Rowley , Kyotaro Horiguchi , Peter Geoghegan , Thomas Munro , Tomas Vondra , Dilip Kumar Subject: Re: Index Skip Scan (new UniqueKeys) Message-ID: <20200711162103.hiygat3k6wu2d25p@localhost> References: <20200609102247.jdlatmfyeecg52fi@localhost> <20200629120709.52w2zi36mtzyliv2@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 Fri, Jul 10, 2020 at 05:03:37PM +0000, Floris Van Nee wrote: > > Also took another look at the patch now, and found a case of incorrect > data. It looks related to the new way of creating the paths, as I > can't recall seeing this in earlier versions. > > create table t1 as select a,b,b%5 as c, random() as d from generate_series(1, 10) a, generate_series(1,100) b; > create index on t1 (a,b,c); > > postgres=# explain select distinct on (a) * from t1 order by a,b desc,c; > QUERY PLAN > ------------------------------------------------------------------------------- > Sort (cost=2.92..2.94 rows=10 width=20) > Sort Key: a, b DESC, c > -> Index Scan using t1_a_b_c_idx on t1 (cost=0.28..2.75 rows=10 width=20) > Skip scan: true > (4 rows) Good point, thanks for looking at this. With the latest planner version there are indeed more possibilities to use skipping. It never occured to me that some of those paths will still rely on index scan returning full data set. I'll look in details and add verification to prevent putting something like this on top of skip scan in the next version.