Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0QjU-0006QW-GP for pgsql-performance@arkaria.postgresql.org; Wed, 30 Nov 2022 17:18:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0QjS-0001EA-CK for pgsql-performance@arkaria.postgresql.org; Wed, 30 Nov 2022 17:18:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0QjS-0001E0-2j for pgsql-performance@lists.postgresql.org; Wed, 30 Nov 2022 17:18:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0QjL-00021o-7m for pgsql-performance@lists.postgresql.org; Wed, 30 Nov 2022 17:18:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2AUHIfht1358780; Wed, 30 Nov 2022 12:18:41 -0500 From: Tom Lane To: Igor ALBUQUERQUE SILVA cc: pgsql-performance@lists.postgresql.org Subject: Re: Geometric types row estimation In-reply-to: References: Comments: In-reply-to Igor ALBUQUERQUE SILVA message dated "Wed, 30 Nov 2022 17:44:36 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1358778.1669828721.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2022 12:18:41 -0500 Message-ID: <1358779.1669828721@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Igor ALBUQUERQUE SILVA writes: > I'm having a problem regarding the point type/gist indexes. Here's a > minimal reproduction of it: > ... > What I was expecting is the first query to estimate 4 rows and the secon= d > to estimate 1, like what I get If I try the same thing using integers. Unfortunately, the selectivity estimation functions for PG's geometric types are mostly just stubs. The estimation function for point <@ box in particular is contsel [1]: /* * contsel -- How likely is a box to contain (be contained by) a given box= ? * * This is a tighter constraint than "overlap", so produce a smaller * estimate than areasel does. */ Datum contsel(PG_FUNCTION_ARGS) { PG_RETURN_FLOAT8(0.001); } It's been like that (excepting notational changes) since Berkeley days, because nobody has bothered to make it better. In general, PG's built-in geometric types have never gotten much beyond their origins as an academic proof-of-concept. I think people who are doing serious work that requires such operations mostly use PostGIS, and I'd suggest looking into that. Or, if you feel like doing a lot of work to make these estimators better, have at it. regards, tom lane [1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dblob_plain;f= =3Dsrc/backend/utils/adt/geo_selfuncs.c;hb=3DHEAD