X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id A2594D95D5 for ; Fri, 4 Nov 2005 13:53:10 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 97114-03 for ; Fri, 4 Nov 2005 17:53:09 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 82042D95BA for ; Fri, 4 Nov 2005 13:53:08 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jA4Hr7lV015834; Fri, 4 Nov 2005 12:53:07 -0500 (EST) To: Michal Taborsky Cc: pgsql-performance@postgresql.org Subject: Re: Searching union views not using indices In-reply-to: <436B848F.5030402@mall.cz> References: <436B4836.7030300@mall.cz> <13815.1131118294@sss.pgh.pa.us> <436B848F.5030402@mall.cz> Comments: In-reply-to Michal Taborsky message dated "Fri, 04 Nov 2005 16:55:59 +0100" Date: Fri, 04 Nov 2005 12:53:07 -0500 Message-ID: <15833.1131126787@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.006 required=5 tests=[AWL=0.006] X-Spam-Score: 0.006 X-Spam-Level: X-Archive-Number: 200511/84 X-Sequence-Number: 15341 Michal Taborsky writes: > OK. Mystery (sort of) solved. After you told me it works for you I had > to assume the problem was somewhere else. And, indeed, it was, though > it's not too obvious. > The two attributes are actually not of tybe bigint, but of type > "crm_object_id", which is created as follows: > CREATE DOMAIN "public"."crm_object_id" AS > bigint NULL; Ah. The problem is that the UNION's output column is bigint, and the type discrepancy (bigint above, domain below) discourages the planner from pushing down the WHERE condition. There's a related complaint here: http://archives.postgresql.org/pgsql-bugs/2005-10/msg00227.php If we were to change things so that the result of the UNION were still the domain, not plain bigint, then your example would be optimized the way you want. I'm unsure about what other side-effects that would have though. regards, tom lane