Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2ILW-000688-2J for pgsql-hackers@arkaria.postgresql.org; Mon, 16 May 2016 13:14:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b2ILV-00065O-KF for pgsql-hackers@arkaria.postgresql.org; Mon, 16 May 2016 13:14:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b2IKA-0004Yq-6f for pgsql-hackers@postgresql.org; Mon, 16 May 2016 13:12:42 +0000 Received: from newmail.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2IK6-0000bz-GG for pgsql-hackers@postgresql.org; Mon, 16 May 2016 13:12:41 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 0B14321C6BAF for ; Mon, 16 May 2016 16:12:37 +0300 (MSK) Received: from mail.postgrespro.ru ([127.0.0.1]) by localhost (mail.postgrespro.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DelnKzufD1Sk for ; Mon, 16 May 2016 16:12:34 +0300 (MSK) Received: from [192.168.27.107] (unknown [192.168.27.1]) by mail.postgrespro.ru (Postfix) with ESMTPSA id B185E21C1768 for ; Mon, 16 May 2016 16:12:34 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1463404354; bh=k4DGM8m7VZU1jmVFADFSOsaTdE8yMQZUWFwR6PC2NEM=; h=Subject:To:References:From:Date:In-Reply-To; b=W2Hq8ysS5AY4HMddYVcL0/36fsNvt1TmemkWW6pC9qCOGcGrtaxau7yCV8vL2A2L0 8do4OnhobeQH9oOyEbIvfR0zcpLxiekMOTmYWaE5cIq1r5VdtgOtKszo8JrKjjc1Qg BSEMhtRXkqjJRNhshCeZLdIZKfraDDxbiP+4HvbU= Subject: Re: Declarative partitioning To: pgsql-hackers@postgresql.org 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> From: Ildar Musin Message-ID: <5739C742.80504@postgrespro.ru> Date: Mon, 16 May 2016 16:12:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57183572.8020900@lab.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -3.4 (---) 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 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? Thanks! -- Ildar Musin i.musin@postgrespro.ru -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers