Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VgyPC-0007Hf-EI for pgsql-performance@arkaria.postgresql.org; Thu, 14 Nov 2013 15:00:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VgyPB-0005Cn-U5 for pgsql-performance@arkaria.postgresql.org; Thu, 14 Nov 2013 15:00:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VgyPB-0005Ch-3d for pgsql-performance@postgresql.org; Thu, 14 Nov 2013 15:00:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VgyP4-0007CK-If for pgsql-performance@postgresql.org; Thu, 14 Nov 2013 15:00:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id rAEF0EY1001720; Thu, 14 Nov 2013 10:00:14 -0500 From: Tom Lane To: Dieter Komendera cc: pgsql-performance@postgresql.org Subject: Re: Bad plan choices & statistic targets with a GIN index In-reply-to: <675CE272-1EE1-4366-BF94-5E1AC075B5A5@komendera.com> References: <675CE272-1EE1-4366-BF94-5E1AC075B5A5@komendera.com> Comments: In-reply-to Dieter Komendera message dated "Thu, 14 Nov 2013 15:36:57 +0100" Date: Thu, 14 Nov 2013 10:00:14 -0500 Message-ID: <1719.1384441214@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Dieter Komendera writes: > Because I didn't find any documentation or references on setting statistic targets on indices, I just gave it a shot: > ALTER TABLE index_games_participants ALTER COLUMN "array" SET STATISTICS 1000; This works, and will help if the planner can make use of statistics on the expression the index is indexing. The reason it's not documented is that it's not considered supported (yet), primarily because pg_dump won't dump such a setting. And the reason for that is mainly that the column names of an index aren't guaranteed stable across PG versions. But as long as you're willing to remember to restore the setting manually, it's a reasonable thing to do if it helps your query plans. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance