Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XpK1h-00007I-IR for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Nov 2014 16:47:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XpK1g-0005Hf-Qy for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Nov 2014 16:47:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XpK1f-0005HS-Qy for pgsql-hackers@postgresql.org; Fri, 14 Nov 2014 16:47:11 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XpK1c-00065D-VO for pgsql-hackers@postgresql.org; Fri, 14 Nov 2014 16:47:10 +0000 Received: from intern.anarazel.de (p54AF4A9C.dip0.t-ipconnect.de [84.175.74.156]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id DD08D460002; Fri, 14 Nov 2014 17:47:05 +0100 (CET) Date: Fri, 14 Nov 2014 17:47:05 +0100 From: Andres Freund To: Robert Haas Cc: Peter Eisentraut , Michael Paquier , Jim Nasby , PostgreSQL mailing lists Subject: Re: REINDEX CONCURRENTLY 2.0 Message-ID: <20141114164705.GF11733@alap3.anarazel.de> References: <20140827064120.GZ21544@awork2.anarazel.de> <545B8AD2.8030203@gmx.net> <20141112213912.GH13473@awork2.anarazel.de> <20141113003106.GJ13473@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -1.1 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2014-11-13 11:41:18 -0500, Robert Haas wrote: > On Wed, Nov 12, 2014 at 7:31 PM, Andres Freund wrote: > > But I think it won't work realistically. We have a *lot* of > > infrastructure that refers to indexes using it's primary key. I don't > > think we want to touch all those places to also disambiguate on some > > other factor. All the relevant APIs are either just passing around oids > > or relcache entries. > > I'm not quite following this. The whole point is to AVOID having two > indexes. You have one index which may at times have two sets of > physical storage. Right. But how are we going to refer to these different relfilenodes? All the indexing infrastructure just uses oids and/or Relation pointers to refer to the index. How would you hand down the knowledge which of the relfilenodes is supposed to be used in some callchain? There's ugly solutions like having a flag like 'bool rd_useotherfilenode' inside struct RelationData, but even ignoring the uglyness I don't think that'd work well - what if some function called inside the index code again starts a index lookup? I think I might just not getting your idea here? > > And all the > > indexing infrastructure can't deal with that without having separate > > oids & relcache entries. Hopefully explained above? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers