database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Improve selectivity estimation for assorted match-style operators.

Browse Source 
Quite a few matching operators such as JSONB's @> used "contsel" and
"contjoinsel" as their selectivity estimators.  That was a bad idea,
because (a) contsel is only a stub, yielding a fixed default estimate,
and (b) that default is 0.001, meaning we estimate these operators as
five times more selective than equality, which is surely pretty silly.

There's a good model for improving this in ltree's ltreeparentsel():
for any "var OP constant" query, we can try applying the operator
to all of the column's MCV and histogram values, taking the latter
as being a random sample of the non-MCV values.  That code is
actually 100% generic, except for the question of exactly what
default selectivity ought to be plugged in when we don't have stats.

Hence, migrate the guts of ltreeparentsel() into the core code, provide
wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate
default estimate, and use those for the non-geometric operators that
formerly used contsel (mostly JSONB containment operators and tsquery
matching).

Also apply this code to some match-like operators in hstore, ltree, and
pg_trgm, including the former users of ltreeparentsel as well as ones
that improperly used contsel.  Since commit 911e70207 just created new
versions of those extensions that we haven't released yet, we can sneak
this change into those new versions instead of having to create an
additional generation of update scripts.

Patch by me, reviewed by Alexey Bashtanov

Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2020-04-01 10:32:33 -04:00
parent d8653f4687
commit a80818605e
11 changed files with 332 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/src/sgml/xoper.sgml
View File

@ -282,6 +282,18 @@ column OP constant
estimates won't be as good as they could be.
</para>
<para>
Another useful built-in selectivity estimation function
is <function>matchingsel</function>, which will work for almost any
binary operator, if standard MCV and/or histogram statistics are
collected for the input data type(s). Its default estimate is set to
twice the default estimate used in <function>eqsel</function>, making
it most suitable for comparison operators that are somewhat less
strict than equality. (Or you could call the
underlying <function>generic_restriction_selectivity</function>
function, providing a different default estimate.)
</para>
<para>
There are additional selectivity estimation functions designed for geometric
operators in <filename>src/backend/utils/adt/geo_selfuncs.c</filename>: <function>areasel</function>, <function>positionsel</function>,
@ -319,6 +331,7 @@ table1.column1 OP table2.column2
<member><function>scalarlejoinsel</function> for <literal>&lt;=</literal></member>
<member><function>scalargtjoinsel</function> for <literal>&gt;</literal></member>
<member><function>scalargejoinsel</function> for <literal>&gt;=</literal></member>
<member><function>matchingjoinsel</function> for generic matching operators</member>
<member><function>areajoinsel</function> for 2D area-based comparisons</member>
<member><function>positionjoinsel</function> for 2D position-based comparisons</member>
<member><function>contjoinsel</function> for 2D containment-based comparisons</member>