Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2ZtR-0002Bp-8O for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2016 07:58:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b2ZtQ-0004Wi-ND for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2016 07:58:16 +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 1b2Zs5-0002xz-3x for pgsql-hackers@postgresql.org; Tue, 17 May 2016 07:56:53 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2Zs0-0006cM-Cj for pgsql-hackers@postgresql.org; Tue, 17 May 2016 07:56:51 +0000 Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id u4H7uhxZ014768; Tue, 17 May 2016 16:56:43 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 1E6A05F612; Tue, 17 May 2016 16:56:43 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 116355F590; Tue, 17 May 2016 16:56:43 +0900 (JST) Received: from [127.0.0.1] (unknown [129.60.241.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTP id F22654007EF; Tue, 17 May 2016 16:56:42 +0900 (JST) Subject: Re: Declarative partitioning References: <55D3093C.5010800@lab.ntt.co.jp> <56DE2D4B.1040001@lab.ntt.co.jp> <56DF74F0.7060404@lab.ntt.co.jp> <56F0AC96.2010303@lab.ntt.co.jp> <57106F9E.3000309@lab.ntt.co.jp> <57163954.2020701@postgrespro.ru> <571759D8.7030205@lab.ntt.co.jp> <57179653.30905@postgrespro.ru> <57183572.8020900@lab.ntt.co.jp> <5739C742.80504@postgrespro.ru> From: Amit Langote Message-ID: <573ACEB2.1090705@lab.ntt.co.jp> Date: Tue, 17 May 2016 16:56:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5739C742.80504@postgrespro.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Ildar Musin , pgsql-hackers@postgresql.org X-TM-AS-MML: disable X-Pg-Spam-Score: -4.0 (----) 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 Hi Ildar, On 2016/05/16 22:12, Ildar Musin wrote: > Hi Amit, > > I'm running some experiments based on your infrastructure trying to > optimize SELECT queries. At some point I need to get PartitionDesc for > relation and to do it I'm using RelationGetPartitionDesc() function. > Problem is that this function copies relcache data and it can be quite > slow for large amounts (thousands) of partitions. The comment to the > function says that we cannot use relation->rd_partdesc pointer to relcache > because of possibility of relcache invalidation. Could you please tell is > it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE > query? Hmm, I think invalidation would not occur mid-query since it would have acquired a lock on the table. So the copying may be unnecessary though I may be wrong. I will study other similar code and see if that is so. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers