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 1hilD8-0007kV-9K for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jul 2019 19:46:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hilD7-0005Ge-39 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jul 2019 19:46:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hilD6-0005GW-O4 for pgsql-hackers@lists.postgresql.org; Wed, 03 Jul 2019 19:46:32 +0000 Received: from xvm-110-146.dc2.ghst.net ([46.226.110.146] helo=fetter.org) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hilD4-0007qH-BD for pgsql-hackers@postgresql.org; Wed, 03 Jul 2019 19:46:31 +0000 Received: by fetter.org (Postfix, from userid 1001) id 4C0D44096D; Wed, 3 Jul 2019 21:46:28 +0200 (CEST) Date: Wed, 3 Jul 2019 21:46:28 +0200 From: David Fetter To: David Rowley Cc: Thomas Munro , Jesper Pedersen , Dmitry Dolgov <9erthalion6@gmail.com>, Floris Van Nee , James Coleman , Rafia Sabih , Jeff Janes , Peter Geoghegan , Tomas Vondra , Thomas Munro , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov Subject: Re: Index Skip Scan Message-ID: <20190703194627.GA24679@fetter.org> References: <1559763453006.85615@Optiver.com> <1559763570329.85227@Optiver.com> <4d469bf2-49ff-bc3d-a428-6c7b5d87d526@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jul 03, 2019 at 12:27:09AM +1200, David Rowley wrote: > On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote: > > The more I think about these UniqueKeys, the more I think they need to > be a separate concept to PathKeys. For example, UniqueKeys: { x, y } > should be equivalent to { y, x }, but with PathKeys, that's not the > case, since the order of each key matters. UniqueKeys equivalent > version of pathkeys_contained_in() would not care about the order of > individual keys, it would say things like, { a, b, c } is contained in > { b, a }, since if the path is unique on columns { b, a } then it must > also be unique on { a, b, c }. Is that actually true, though? I can see unique {a, b, c} => unique {a, b}, but for example: a | b | c --|---|-- 1 | 2 | 3 1 | 2 | 4 1 | 2 | 5 is unique on {a, b, c} but not on {a, b}, at least as I understand the way "unique" is used here, which is 3 distinct {a, b, c}, but only one {a, b}. Or I could be missing something obvious, and in that case, please ignore. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate