Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5Fdb-0003Uc-Fh for pgsql-performance@arkaria.postgresql.org; Fri, 02 Aug 2013 13:43:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1V5Fda-0007ln-Vy for pgsql-performance@arkaria.postgresql.org; Fri, 02 Aug 2013 13:43:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5Fda-0007lh-8u for pgsql-performance@postgresql.org; Fri, 02 Aug 2013 13:43:22 +0000 Received: from gmmr2.centrum.cz ([2a00:da80:1:502::2]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5FdW-0000Yf-OT for pgsql-performance@postgresql.org; Fri, 02 Aug 2013 13:43:21 +0000 Received: from mail1008.cent (unknown [10.32.3.103]) by gmmr2.centrum.cz (Postfix) with ESMTP id 0035660000B4 for ; Fri, 2 Aug 2013 15:43:16 +0200 (CEST) Received: by mail1008.cent (Postfix, from userid 33) id EED38408C225A; Fri, 2 Aug 2013 15:43:16 +0200 (CEST) To: Subject: =?utf-8?q?Sub=2Doptimal_plan_for_a_paginated_query_on_a_view_with_another_view_inside_of_it=2E?= Received: from 195.168.8.115 (X-Forwarded-For: 195.168.8.115) by mail1008.centrum.cz (centrum.cz multimail) with HTTP Date: Fri, 02 Aug 2013 15:43:16 +0200 From: X-Mailer: Centrum Email 5.3 X-Priority: 3 X-Original-From: slapo@centrum.sk MIME-Version: 1.0 Message-Id: <20130802154316.59167BB5@centrum.sk> X-Maser: oho Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Good day,   I have a performance issue when JOINing a view within another view more than once. The query takes over three seconds to execute, which is too long in this case. It's not a problem if the tables are nearly empty, but that isn't the case on the production database.   I suspect the planner thinks it's better to first put together the v_address view and JOIN it to the parcel table later on, but the function "fx_get_user_tree_subordinates_by_id" should be JOINed to the parcel table first, as it reduces the number of rows to less than 200 and any following JOINs would be much faster.   I have also ran vacuum, reindex and analyze on the whole database, but it seems to have had to effect.   Is there any way to nudge the planner toward that way of execution?   This is the query: https://app.box.com/s/jzxiuuxoyj28q4q8rzxr   This is the query plan: https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h (plain text) https://app.box.com/s/jzxiuuxoyj28q4q8rzxr (graphical output)   These are the views: https://app.box.com/s/uibzidsazwv3eeauovuk (paginated view) https://app.box.com/s/v71vyexmdyl97m4f3m6u (used three times in the paginated view).     Thank you.   Peter Slapansky -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance