Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1snvgL-0070aq-5F for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Sep 2024 07:53:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1snvgJ-008jwS-Md for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Sep 2024 07:52:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1snvgJ-008jwE-Dy for pgsql-bugs@lists.postgresql.org; Tue, 10 Sep 2024 07:52:59 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1snvgG-000RFt-41 for pgsql-bugs@postgresql.org; Tue, 10 Sep 2024 07:52:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version :References:Reply-To:Message-ID:Subject:Cc:To:Sender:From:Date:Content-ID: Content-Description; bh=tIMmvdlMte0BcbtjwNnr3OkCWmRWp8/dGI1rvIHD1YY=; b=lSUW3 HZjAUZF7rXIzjOAPrOnTN39DPnkg4gUNK7vIp8LR2jaJtSNUE4l1LuKn26CnBQ9xk73cnQ7Go1mmK PREyirr6U+uIYAaEXhr1Lv5sN4pWoBEHZnVOpXnS3Vjm+woo90iJSE0q6sABfBobH4zaHhaPBjCQi vBCwCVVzInOk=; Received: from depesz by depesz.com with local (Exim 4.96) (envelope-from ) id 1snvgG-008PP0-27; Tue, 10 Sep 2024 09:52:56 +0200 Date: Tue, 10 Sep 2024 09:52:56 +0200 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Sanskar Agrawal Cc: pgsql-bugs mailing list Subject: Re: BUG #18607: UNION ALL discards all foreign key relations + indexes Message-ID: Reply-To: depesz@depesz.com References: <18607-651aa996c1e71d48@postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 10, 2024 at 01:20:22PM +0530, Sanskar Agrawal wrote: > As you can see in the below screenshot if the view is defined with a UNION > ALL it tends to drop the index + relations. > > [image: Screenshot 2024-09-10 at 1.17.27 PM.png] > > But if the same query is replaced with below, the constraints stay. > > [image: Screenshot 2024-09-10 at 1.18.59 PM.png] > > What I want to emphasize is after a "UNION ALL", > if I want to further process on the unioned set -> it loses its indexes + > relations which then makes the query planner opt in for a seq scan and > table scans. UNION ALL is irrelevant. There is no such thing as index on view. There are indexes on materialized views, but not on plain, standard views. View is just a rule to change query - there is nothing to index. When you query view, pg will change your query to get data from underlying table(s), and if there are suitable views *ON THE TABLE(S)* - they will be used. Best regards, depesz