Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 79A4E632C1D for ; Fri, 3 Sep 2010 11:15:30 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 71883-01 for ; Fri, 3 Sep 2010 14:15:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by mail.postgresql.org (Postfix) with ESMTP id 63FD8632BC7 for ; Fri, 3 Sep 2010 11:15:22 -0300 (ADT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OrX31-0000rK-AW for pgsql-performance@postgresql.org; Fri, 03 Sep 2010 14:15:19 +0000 Received: by bfk.de with local id 1OrX31-0005Nn-60 for pgsql-performance@postgresql.org; Fri, 03 Sep 2010 14:15:19 +0000 To: pgsql-performance@postgresql.org Subject: Odd estimation issue with user-defined type From: Florian Weimer Date: Fri, 03 Sep 2010 14:15:19 +0000 Message-ID: <82zkvyncaw.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201009/6 X-Sequence-Number: 40209 I've created a few user-defined types quite similar to uuid which we use to store various hashes in the database. (The types use binary encoding internally, but only expose hexadecimal strings externally.) The hashes are roughly equidistributed, so when I do a range query which is essentially based on a hash prefix(*), I expect the result to contain N * 2**(-k) results, where N is the table size and k the number of bits in the range. Actual query results show that this is the case. The odd thing is that the planner thinks that the range query will return about one quarter of the table, independently of the range specified. Of course, the row estimates are quite far off as a result, leading to suboptimal plans. Any idea what could cause this? Do I need to provide some estimator function somewhere? (*) I don't use LIKE, because its optimization is hard-coded to a few types, but explicit BETWEEN ... AND queries. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99