Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxEE0-0004GC-Oa for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 14:21:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bxEE0-0001Fb-2X for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 14:21:40 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxEDy-0001E6-6H for pgsql-hackers@postgresql.org; Thu, 20 Oct 2016 14:21:38 +0000 Received: from smtprelay0231.b.hostedemail.com ([64.98.42.231] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxEDu-00073j-Bi for pgsql-hackers@postgresql.org; Thu, 20 Oct 2016 14:21:37 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay04.b.hostedemail.com (Postfix) with ESMTP id DEA357B8C5; Thu, 20 Oct 2016 14:21:32 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::::::::::::,RULES_HIT:41:355:379:599:967:973:981:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4362:4605:5007:6261:7875:7903:8694:9025:9121:10004:10400:10848:11232:11658:11914:12663:13069:13141:13161:13229:13230:13311:13357:13439:13894:13895:14721:14764:21080:30012:30054,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:7,LUA_SUMMARY:none X-HE-Tag: grain84_2a70a5ed29117 X-Filterd-Recvd-Size: 2378 Received: from alvin.alvh.no-ip.org (unknown [186.11.38.26]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf12.b.hostedemail.com (Postfix) with ESMTPA; Thu, 20 Oct 2016 14:21:31 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id D59C42A9F; Thu, 20 Oct 2016 11:21:28 -0300 (CLST) Date: Thu, 20 Oct 2016 11:21:28 -0300 From: Alvaro Herrera To: "Joshua D. Drake" Cc: Bruce Momjian , Simon Riggs , Pavan Deolasee , Alexander Korotkov , Robert Haas , Pg Hackers Subject: Re: Indirect indexes Message-ID: <20161020142128.2qqk7lowoz4ro6wc@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2a89563d-99d0-f304-1b0f-1f33bac4fd62@commandprompt.com> User-Agent: NeoMutt/20161003 (1.7.0) X-Pg-Spam-Score: -1.9 (-) 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 Joshua D. Drake wrote: > That said would it be possible to make this index an extension (like rum?). > Assuming of course we can get any required infrastructure changes done in a > general way. Well, the patch I currently have creates a separate index AM called "ibtree" which is an indirect btree that internally calls the regular btree code -- pretty much what you propose. I think it can work that way, but it's not as efficient as it can be done if the feature is incorporated into core. There are things like obtaining the primary key value from the indexed tuple: in my extension I simply do "heap_fetch" to obtain the heap tuple, then heap_getattr() to obtain the values from the primary key columns. This works, but if instead the executor passes the primary key values as parameters, I can save both those steps, which are slow. Now if we do incorporate the infrastructure changes in core in a general way, which is what I am proposing, then the in-core provided btree AM can do indirect indexes without any further extension. The same infrastructure changes can later provide support for GIN indexes. > I do think the feature has merit. Thanks. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers