On 21.01.2020 0:00, Darafei "Komяpa" Praliaskouski wrote:
Hi,
Found out today that BRIN indexes don't really work for PostGIS and
box datatypes.
Since
https://github.com/postgres/postgres/commit/7e534adcdc70866e7be74d626b0ed067c890a251 Postgres
requires datatype to provide correlation statistics. Such statistics
wasn't provided by PostGIS and box types.
Today I tried to replace a 200gb gist index with 8mb brin index and
queries didn't work as expected - it was never used. set
enable_seqscan=off helped for a bit but that's not a permanent solution.
Plans for context:
https://gist.github.com/Komzpa/2cd396ec9b65e2c93341e9934d974826
Debugging session on #postgis IRC channel leads to this ticket to
create a (not that meaningful) correlation statistics for geometry
datatype: https://trac.osgeo.org/postgis/ticket/4625#ticket
Postgres Professional mentioned symptoms of the issue in their
in-depth manual:
https://habr.com/ru/company/postgrespro/blog/346460/ - box datatype
showed same unusable BRIN symptoms for them.
(Translated to English:
https://habr.com/en/company/postgrespro/blog/452900/)
A reasonable course of action on Postgres side seems to be to not
assume selectivity of 1 in absence of correlation statistics, but
something that would prefer such an index to a parallel seq scan, but
higher than similar GIST.
Any other ideas?
As far as I understand, correlation is computed only for sortable types,
which means that the current concept of correlation works as intended
only for B-tree indexes.
Ideally, correlation should be computed for (attribute, index) pair,
taking into account order of values returned by the index scan. Less
ideal but more easier approach can be to ignore the computed correlation
for any index access except B-tree, and just assume some predefined
constant.
