Igor ALBUQUERQUE SILVA <i.albuquerque-silva@xxxxxxxxxxx> 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 second > 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=postgresql.git;a=blob_plain;f=src/backend/utils/adt/geo_selfuncs.c;hb=HEAD