Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
-- Generic extended statistics support
|
2017-03-27 17:40:42 +02:00
|
|
|
-- We will be checking execution plans without/with statistics, so
|
|
|
|
-- let's make sure we get simple non-parallel plans. Also set the
|
|
|
|
-- work_mem low so that we can use small amounts of data.
|
2019-04-16 00:02:22 +02:00
|
|
|
-- check the number of estimated/actual rows in the top node
|
|
|
|
create function check_estimated_rows(text) returns table (estimated int, actual int)
|
|
|
|
language plpgsql as
|
|
|
|
$$
|
|
|
|
declare
|
|
|
|
ln text;
|
|
|
|
tmp text[];
|
|
|
|
first_row bool := true;
|
|
|
|
begin
|
|
|
|
for ln in
|
|
|
|
execute format('explain analyze %s', $1)
|
|
|
|
loop
|
|
|
|
if first_row then
|
|
|
|
first_row := false;
|
|
|
|
tmp := regexp_match(ln, 'rows=(\d*) .* rows=(\d*)');
|
|
|
|
return query select tmp[1]::int, tmp[2]::int;
|
|
|
|
end if;
|
|
|
|
end loop;
|
|
|
|
end;
|
|
|
|
$$;
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
-- Verify failures
|
|
|
|
CREATE STATISTICS tst;
|
|
|
|
ERROR: syntax error at or near ";"
|
|
|
|
LINE 1: CREATE STATISTICS tst;
|
|
|
|
^
|
|
|
|
CREATE STATISTICS tst ON a, b;
|
|
|
|
ERROR: syntax error at or near ";"
|
|
|
|
LINE 1: CREATE STATISTICS tst ON a, b;
|
|
|
|
^
|
|
|
|
CREATE STATISTICS tst FROM sometab;
|
|
|
|
ERROR: syntax error at or near "FROM"
|
|
|
|
LINE 1: CREATE STATISTICS tst FROM sometab;
|
|
|
|
^
|
2019-06-08 19:12:26 +02:00
|
|
|
CREATE STATISTICS tst ON a, b FROM nonexistent;
|
|
|
|
ERROR: relation "nonexistent" does not exist
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tst ON a, b FROM pg_class;
|
2017-09-11 17:20:47 +02:00
|
|
|
ERROR: column "a" does not exist
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tst ON relname, relname, relnatts FROM pg_class;
|
|
|
|
ERROR: duplicate column name in statistics definition
|
|
|
|
CREATE STATISTICS tst ON relnatts + relpages FROM pg_class;
|
|
|
|
ERROR: only simple column references are allowed in CREATE STATISTICS
|
|
|
|
CREATE STATISTICS tst ON (relpages, reltuples) FROM pg_class;
|
|
|
|
ERROR: only simple column references are allowed in CREATE STATISTICS
|
|
|
|
CREATE STATISTICS tst (unrecognized) ON relname, relnatts FROM pg_class;
|
2017-09-11 17:20:47 +02:00
|
|
|
ERROR: unrecognized statistics kind "unrecognized"
|
2017-06-22 19:17:08 +02:00
|
|
|
-- Ensure stats are dropped sanely, and test IF NOT EXISTS while at it
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
CREATE TABLE ab1 (a INTEGER, b INTEGER, c INTEGER);
|
2017-06-22 19:17:08 +02:00
|
|
|
CREATE STATISTICS IF NOT EXISTS ab1_a_b_stats ON a, b FROM ab1;
|
|
|
|
CREATE STATISTICS IF NOT EXISTS ab1_a_b_stats ON a, b FROM ab1;
|
|
|
|
NOTICE: statistics object "ab1_a_b_stats" already exists, skipping
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
DROP STATISTICS ab1_a_b_stats;
|
|
|
|
CREATE SCHEMA regress_schema_2;
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS regress_schema_2.ab1_a_b_stats ON a, b FROM ab1;
|
2017-05-14 16:54:47 +02:00
|
|
|
-- Let's also verify the pg_get_statisticsobjdef output looks sane.
|
|
|
|
SELECT pg_get_statisticsobjdef(oid) FROM pg_statistic_ext WHERE stxname = 'ab1_a_b_stats';
|
|
|
|
pg_get_statisticsobjdef
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
-------------------------------------------------------------------
|
|
|
|
CREATE STATISTICS regress_schema_2.ab1_a_b_stats ON a, b FROM ab1
|
2017-03-27 05:53:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
DROP STATISTICS regress_schema_2.ab1_a_b_stats;
|
|
|
|
-- Ensure statistics are dropped when columns are
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS ab1_b_c_stats ON b, c FROM ab1;
|
|
|
|
CREATE STATISTICS ab1_a_b_c_stats ON a, b, c FROM ab1;
|
2017-05-12 22:26:31 +02:00
|
|
|
CREATE STATISTICS ab1_b_a_stats ON b, a FROM ab1;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ALTER TABLE ab1 DROP COLUMN a;
|
|
|
|
\d ab1
|
|
|
|
Table "public.ab1"
|
|
|
|
Column | Type | Collation | Nullable | Default
|
|
|
|
--------+---------+-----------+----------+---------
|
|
|
|
b | integer | | |
|
|
|
|
c | integer | | |
|
2017-05-14 16:54:47 +02:00
|
|
|
Statistics objects:
|
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
|
|
|
"public"."ab1_b_c_stats" (ndistinct, dependencies, mcv) ON b, c FROM ab1
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
|
2017-05-12 22:26:31 +02:00
|
|
|
-- Ensure statistics are dropped when table is
|
|
|
|
SELECT stxname FROM pg_statistic_ext WHERE stxname LIKE 'ab1%';
|
|
|
|
stxname
|
|
|
|
---------------
|
|
|
|
ab1_b_c_stats
|
|
|
|
(1 row)
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
DROP TABLE ab1;
|
2017-05-12 22:26:31 +02:00
|
|
|
SELECT stxname FROM pg_statistic_ext WHERE stxname LIKE 'ab1%';
|
|
|
|
stxname
|
|
|
|
---------
|
|
|
|
(0 rows)
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
-- Ensure things work sanely with SET STATISTICS 0
|
|
|
|
CREATE TABLE ab1 (a INTEGER, b INTEGER);
|
|
|
|
ALTER TABLE ab1 ALTER a SET STATISTICS 0;
|
|
|
|
INSERT INTO ab1 SELECT a, a%23 FROM generate_series(1, 1000) a;
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS ab1_a_b_stats ON a, b FROM ab1;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ANALYZE ab1;
|
2017-05-14 16:54:47 +02:00
|
|
|
WARNING: statistics object "public.ab1_a_b_stats" could not be computed for relation "public.ab1"
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ALTER TABLE ab1 ALTER a SET STATISTICS -1;
|
2017-04-17 19:00:47 +02:00
|
|
|
-- partial analyze doesn't build stats either
|
|
|
|
ANALYZE ab1 (a);
|
2017-05-14 16:54:47 +02:00
|
|
|
WARNING: statistics object "public.ab1_a_b_stats" could not be computed for relation "public.ab1"
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ANALYZE ab1;
|
|
|
|
DROP TABLE ab1;
|
2017-04-17 22:55:17 +02:00
|
|
|
-- Verify supported object types for extended statistics
|
|
|
|
CREATE schema tststats;
|
|
|
|
CREATE TABLE tststats.t (a int, b int, c text);
|
|
|
|
CREATE INDEX ti ON tststats.t (a, b);
|
|
|
|
CREATE SEQUENCE tststats.s;
|
|
|
|
CREATE VIEW tststats.v AS SELECT * FROM tststats.t;
|
|
|
|
CREATE MATERIALIZED VIEW tststats.mv AS SELECT * FROM tststats.t;
|
|
|
|
CREATE TYPE tststats.ty AS (a int, b int, c text);
|
|
|
|
CREATE FOREIGN DATA WRAPPER extstats_dummy_fdw;
|
|
|
|
CREATE SERVER extstats_dummy_srv FOREIGN DATA WRAPPER extstats_dummy_fdw;
|
|
|
|
CREATE FOREIGN TABLE tststats.f (a int, b int, c text) SERVER extstats_dummy_srv;
|
|
|
|
CREATE TABLE tststats.pt (a int, b int, c text) PARTITION BY RANGE (a, b);
|
|
|
|
CREATE TABLE tststats.pt1 PARTITION OF tststats.pt FOR VALUES FROM (-10, -10) TO (10, 10);
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tststats.s1 ON a, b FROM tststats.t;
|
|
|
|
CREATE STATISTICS tststats.s2 ON a, b FROM tststats.ti;
|
2017-04-17 22:55:17 +02:00
|
|
|
ERROR: relation "ti" is not a table, foreign table, or materialized view
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tststats.s3 ON a, b FROM tststats.s;
|
2017-04-17 22:55:17 +02:00
|
|
|
ERROR: relation "s" is not a table, foreign table, or materialized view
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tststats.s4 ON a, b FROM tststats.v;
|
2017-04-17 22:55:17 +02:00
|
|
|
ERROR: relation "v" is not a table, foreign table, or materialized view
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tststats.s5 ON a, b FROM tststats.mv;
|
|
|
|
CREATE STATISTICS tststats.s6 ON a, b FROM tststats.ty;
|
2017-04-17 22:55:17 +02:00
|
|
|
ERROR: relation "ty" is not a table, foreign table, or materialized view
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS tststats.s7 ON a, b FROM tststats.f;
|
|
|
|
CREATE STATISTICS tststats.s8 ON a, b FROM tststats.pt;
|
|
|
|
CREATE STATISTICS tststats.s9 ON a, b FROM tststats.pt1;
|
2017-04-17 22:55:17 +02:00
|
|
|
DO $$
|
|
|
|
DECLARE
|
|
|
|
relname text := reltoastrelid::regclass FROM pg_class WHERE oid = 'tststats.t'::regclass;
|
|
|
|
BEGIN
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
EXECUTE 'CREATE STATISTICS tststats.s10 ON a, b FROM ' || relname;
|
2017-04-17 22:55:17 +02:00
|
|
|
EXCEPTION WHEN wrong_object_type THEN
|
|
|
|
RAISE NOTICE 'stats on toast table not created';
|
|
|
|
END;
|
|
|
|
$$;
|
|
|
|
NOTICE: stats on toast table not created
|
|
|
|
DROP SCHEMA tststats CASCADE;
|
2017-08-01 22:49:23 +02:00
|
|
|
NOTICE: drop cascades to 7 other objects
|
2019-03-25 00:15:37 +01:00
|
|
|
DETAIL: drop cascades to table tststats.t
|
|
|
|
drop cascades to sequence tststats.s
|
|
|
|
drop cascades to view tststats.v
|
|
|
|
drop cascades to materialized view tststats.mv
|
|
|
|
drop cascades to type tststats.ty
|
|
|
|
drop cascades to foreign table tststats.f
|
|
|
|
drop cascades to table tststats.pt
|
2017-04-17 22:55:17 +02:00
|
|
|
DROP FOREIGN DATA WRAPPER extstats_dummy_fdw CASCADE;
|
2017-08-01 22:49:23 +02:00
|
|
|
NOTICE: drop cascades to server extstats_dummy_srv
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
-- n-distinct tests
|
|
|
|
CREATE TABLE ndistinct (
|
|
|
|
filler1 TEXT,
|
|
|
|
filler2 NUMERIC,
|
|
|
|
a INT,
|
|
|
|
b INT,
|
|
|
|
filler3 DATE,
|
|
|
|
c INT,
|
|
|
|
d INT
|
|
|
|
);
|
2017-03-27 17:40:42 +02:00
|
|
|
-- over-estimates when using only per-column statistics
|
|
|
|
INSERT INTO ndistinct (a, b, c, filler1)
|
|
|
|
SELECT i/100, i/100, i/100, cash_words((i/100)::money)
|
2019-04-16 00:02:22 +02:00
|
|
|
FROM generate_series(1,1000) s(i);
|
2017-03-27 17:40:42 +02:00
|
|
|
ANALYZE ndistinct;
|
|
|
|
-- Group Aggregate, due to over-estimate of the number of groups
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
100 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
100 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
100 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
200 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
200 | 11
|
|
|
|
(1 row)
|
2017-03-27 17:40:42 +02:00
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
-- correct command
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS s10 ON a, b, c FROM ndistinct;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ANALYZE ndistinct;
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
SELECT s.stxkind, d.stxdndistinct
|
|
|
|
FROM pg_statistic_ext s, pg_statistic_ext_data d
|
|
|
|
WHERE s.stxrelid = 'ndistinct'::regclass
|
|
|
|
AND d.stxoid = s.oid;
|
|
|
|
stxkind | stxdndistinct
|
2019-04-16 00:02:22 +02:00
|
|
|
---------+-----------------------------------------------------
|
|
|
|
{d,f,m} | {"3, 4": 11, "3, 6": 11, "4, 6": 11, "3, 4, 6": 11}
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
(1 row)
|
|
|
|
|
2017-03-27 17:40:42 +02:00
|
|
|
-- Hash Aggregate, thanks to estimates improved by the statistic
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
11 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
11 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
11 | 11
|
|
|
|
(1 row)
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
|
2017-03-27 17:40:42 +02:00
|
|
|
-- last two plans keep using Group Aggregate, because 'd' is not covered
|
|
|
|
-- by the statistic and while it's NULL-only we assume 200 values for it
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
200 | 11
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
200 | 11
|
|
|
|
(1 row)
|
2017-03-27 17:40:42 +02:00
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
TRUNCATE TABLE ndistinct;
|
2017-03-27 17:40:42 +02:00
|
|
|
-- under-estimates when using only per-column statistics
|
|
|
|
INSERT INTO ndistinct (a, b, c, filler1)
|
|
|
|
SELECT mod(i,50), mod(i,51), mod(i,32),
|
|
|
|
cash_words(mod(i,33)::int::money)
|
2019-04-16 00:02:22 +02:00
|
|
|
FROM generate_series(1,5000) s(i);
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
ANALYZE ndistinct;
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
SELECT s.stxkind, d.stxdndistinct
|
|
|
|
FROM pg_statistic_ext s, pg_statistic_ext_data d
|
|
|
|
WHERE s.stxrelid = 'ndistinct'::regclass
|
|
|
|
AND d.stxoid = s.oid;
|
|
|
|
stxkind | stxdndistinct
|
2019-04-16 00:02:22 +02:00
|
|
|
---------+------------------------------------------------------------
|
|
|
|
{d,f,m} | {"3, 4": 2550, "3, 6": 800, "4, 6": 1632, "3, 4, 6": 5000}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- correct esimates
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
2550 | 2550
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
5000 | 5000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
5000 | 5000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1632 | 1632
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 50
|
|
|
|
(1 row)
|
2017-03-27 17:40:42 +02:00
|
|
|
|
|
|
|
DROP STATISTICS s10;
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
SELECT s.stxkind, d.stxdndistinct
|
|
|
|
FROM pg_statistic_ext s, pg_statistic_ext_data d
|
|
|
|
WHERE s.stxrelid = 'ndistinct'::regclass
|
|
|
|
AND d.stxoid = s.oid;
|
|
|
|
stxkind | stxdndistinct
|
|
|
|
---------+---------------
|
2017-03-27 17:40:42 +02:00
|
|
|
(0 rows)
|
|
|
|
|
2019-04-16 00:02:22 +02:00
|
|
|
-- dropping the statistics results in under-estimates
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 2550
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 5000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 5000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY b, c, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 1632
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT COUNT(*) FROM ndistinct GROUP BY a, d');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
500 | 50
|
|
|
|
(1 row)
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
|
2017-04-06 00:00:42 +02:00
|
|
|
-- functional dependencies tests
|
|
|
|
CREATE TABLE functional_dependencies (
|
|
|
|
filler1 TEXT,
|
|
|
|
filler2 NUMERIC,
|
|
|
|
a INT,
|
|
|
|
b TEXT,
|
|
|
|
filler3 DATE,
|
|
|
|
c INT,
|
|
|
|
d TEXT
|
|
|
|
);
|
|
|
|
CREATE INDEX fdeps_ab_idx ON functional_dependencies (a, b);
|
|
|
|
CREATE INDEX fdeps_abc_idx ON functional_dependencies (a, b, c);
|
|
|
|
-- random data (no functional dependencies)
|
|
|
|
INSERT INTO functional_dependencies (a, b, c, filler1)
|
|
|
|
SELECT mod(i, 23), mod(i, 29), mod(i, 31), i FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE functional_dependencies;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
8 | 8
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 1
|
|
|
|
(1 row)
|
2017-04-06 00:00:42 +02:00
|
|
|
|
|
|
|
-- create statistics
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS func_deps_stat (dependencies) ON a, b, c FROM functional_dependencies;
|
2017-04-06 00:00:42 +02:00
|
|
|
ANALYZE functional_dependencies;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
8 | 8
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 1
|
|
|
|
(1 row)
|
2017-04-06 00:00:42 +02:00
|
|
|
|
|
|
|
-- a => b, a => c, b => c
|
|
|
|
TRUNCATE functional_dependencies;
|
|
|
|
DROP STATISTICS func_deps_stat;
|
|
|
|
INSERT INTO functional_dependencies (a, b, c, filler1)
|
|
|
|
SELECT mod(i,100), mod(i,50), mod(i,25), i FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE functional_dependencies;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
2017-04-06 00:00:42 +02:00
|
|
|
|
|
|
|
-- create statistics
|
Change CREATE STATISTICS syntax
Previously, we had the WITH clause in the middle of the command, where
you'd specify both generic options as well as statistic types. Few
people liked this, so this commit changes it to remove the WITH keyword
from that clause and makes it accept statistic types only. (We
currently don't have any generic options, but if we invent in the
future, we will gain a new WITH clause, probably at the end of the
command).
Also, the column list is now specified without parens, which makes the
whole command look more similar to a SELECT command. This change will
let us expand the command to supporting expressions (not just columns
names) as well as multiple tables and their join conditions.
Tom added lots of code comments and fixed some parts of the CREATE
STATISTICS reference page, too; more changes in this area are
forthcoming. He also fixed a potential problem in the alter_generic
regression test, reducing verbosity on a cascaded drop to avoid
dependency on message ordering, as we do in other tests.
Tom also closed a security bug: we documented that table ownership was
required in order to create a statistics object on it, but didn't
actually implement it.
Implement tab-completion for statistics objects. This can stand some
more improvement.
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql
2017-05-12 19:59:23 +02:00
|
|
|
CREATE STATISTICS func_deps_stat (dependencies) ON a, b, c FROM functional_dependencies;
|
2017-04-06 00:00:42 +02:00
|
|
|
ANALYZE functional_dependencies;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
2017-04-06 00:00:42 +02:00
|
|
|
|
2017-05-14 18:22:16 +02:00
|
|
|
-- check change of column type doesn't break it
|
|
|
|
ALTER TABLE functional_dependencies ALTER COLUMN c TYPE numeric;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
2017-05-14 18:22:16 +02:00
|
|
|
|
|
|
|
ANALYZE functional_dependencies;
|
2019-04-16 00:02:22 +02:00
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM functional_dependencies WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
|
|
|
-- MCV lists
|
|
|
|
CREATE TABLE mcv_lists (
|
|
|
|
filler1 TEXT,
|
|
|
|
filler2 NUMERIC,
|
|
|
|
a INT,
|
|
|
|
b VARCHAR,
|
|
|
|
filler3 DATE,
|
|
|
|
c INT,
|
|
|
|
d TEXT
|
|
|
|
);
|
|
|
|
-- random data (no MCV list)
|
|
|
|
INSERT INTO mcv_lists (a, b, c, filler1)
|
|
|
|
SELECT mod(i,37), mod(i,41), mod(i,43), mod(i,47) FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
3 | 4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- create statistics
|
|
|
|
CREATE STATISTICS mcv_lists_stats (mcv) ON a, b, c FROM mcv_lists;
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
3 | 4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- 100 distinct combinations, all in the MCV list
|
|
|
|
TRUNCATE mcv_lists;
|
|
|
|
DROP STATISTICS mcv_lists_stats;
|
|
|
|
INSERT INTO mcv_lists (a, b, c, filler1)
|
|
|
|
SELECT mod(i,100), mod(i,50), mod(i,25), i FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a < 1 AND b < ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a <= 0 AND b <= ''0''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a < 5 AND b < ''1'' AND c < 5');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a <= 4 AND b <= ''0'' AND c <= 4');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- create statistics
|
|
|
|
CREATE STATISTICS mcv_lists_stats (mcv) ON a, b, c FROM mcv_lists;
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a < 1 AND b < ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a <= 0 AND b <= ''0''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1'' AND c = 1');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a < 5 AND b < ''1'' AND c < 5');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a <= 4 AND b <= ''0'' AND c <= 4');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- check change of unrelated column type does not reset the MCV statistics
|
|
|
|
ALTER TABLE mcv_lists ALTER COLUMN d TYPE VARCHAR(64);
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
SELECT d.stxdmcv IS NOT NULL
|
|
|
|
FROM pg_statistic_ext s, pg_statistic_ext_data d
|
|
|
|
WHERE s.stxname = 'mcv_lists_stats'
|
|
|
|
AND d.stxoid = s.oid;
|
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- check change of column type resets the MCV statistics
|
|
|
|
ALTER TABLE mcv_lists ALTER COLUMN c TYPE numeric;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a = 1 AND b = ''1''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- 100 distinct combinations with NULL values, all in the MCV list
|
|
|
|
TRUNCATE mcv_lists;
|
|
|
|
DROP STATISTICS mcv_lists_stats;
|
|
|
|
INSERT INTO mcv_lists (a, b, c, filler1)
|
|
|
|
SELECT
|
|
|
|
(CASE WHEN mod(i,100) = 1 THEN NULL ELSE mod(i,100) END),
|
|
|
|
(CASE WHEN mod(i,50) = 1 THEN NULL ELSE mod(i,50) END),
|
|
|
|
(CASE WHEN mod(i,25) = 1 THEN NULL ELSE mod(i,25) END),
|
|
|
|
i
|
|
|
|
FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a IS NULL AND b IS NULL');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a IS NULL AND b IS NULL AND c IS NULL');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- create statistics
|
|
|
|
CREATE STATISTICS mcv_lists_stats (mcv) ON a, b, c FROM mcv_lists;
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a IS NULL AND b IS NULL');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE a IS NULL AND b IS NULL AND c IS NULL');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
50 | 50
|
|
|
|
(1 row)
|
|
|
|
|
2019-04-16 00:01:39 +02:00
|
|
|
-- test pg_mcv_list_items with a very simple (single item) MCV list
|
|
|
|
TRUNCATE mcv_lists;
|
|
|
|
INSERT INTO mcv_lists (a, b, c) SELECT 1, 2, 3 FROM generate_series(1,1000) s(i);
|
|
|
|
ANALYZE mcv_lists;
|
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
|
|
|
SELECT m.*
|
|
|
|
FROM pg_statistic_ext s, pg_statistic_ext_data d,
|
|
|
|
pg_mcv_list_items(d.stxdmcv) m
|
|
|
|
WHERE s.stxname = 'mcv_lists_stats'
|
|
|
|
AND d.stxoid = s.oid;
|
2019-07-04 23:43:04 +02:00
|
|
|
index | values | nulls | frequency | base_frequency
|
|
|
|
-------+---------+---------+-----------+----------------
|
|
|
|
0 | {1,2,3} | {f,f,f} | 1 | 1
|
2019-04-16 00:01:39 +02:00
|
|
|
(1 row)
|
|
|
|
|
2019-07-15 02:00:31 +02:00
|
|
|
-- 2 distinct combinations with NULL values, all in the MCV list
|
|
|
|
TRUNCATE mcv_lists;
|
|
|
|
DROP STATISTICS mcv_lists_stats;
|
|
|
|
INSERT INTO mcv_lists (a, b, c, d)
|
|
|
|
SELECT
|
|
|
|
(CASE WHEN mod(i,2) = 0 THEN NULL ELSE 0 END),
|
|
|
|
(CASE WHEN mod(i,2) = 0 THEN NULL ELSE 'x' END),
|
|
|
|
(CASE WHEN mod(i,2) = 0 THEN NULL ELSE 0 END),
|
|
|
|
(CASE WHEN mod(i,2) = 0 THEN NULL ELSE 'x' END)
|
|
|
|
FROM generate_series(1,5000) s(i);
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE b = ''x'' OR d = ''x''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
3750 | 2500
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- create statistics
|
|
|
|
CREATE STATISTICS mcv_lists_stats (mcv) ON b, d FROM mcv_lists;
|
|
|
|
ANALYZE mcv_lists;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists WHERE b = ''x'' OR d = ''x''');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
2500 | 2500
|
|
|
|
(1 row)
|
|
|
|
|
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
|
|
|
-- mcv with arrays
|
|
|
|
CREATE TABLE mcv_lists_arrays (
|
|
|
|
a TEXT[],
|
|
|
|
b NUMERIC[],
|
|
|
|
c INT[]
|
|
|
|
);
|
|
|
|
INSERT INTO mcv_lists_arrays (a, b, c)
|
|
|
|
SELECT
|
|
|
|
ARRAY[md5((i/100)::text), md5((i/100-1)::text), md5((i/100+1)::text)],
|
|
|
|
ARRAY[(i/100-1)::numeric/1000, (i/100)::numeric/1000, (i/100+1)::numeric/1000],
|
|
|
|
ARRAY[(i/100-1), i/100, (i/100+1)]
|
|
|
|
FROM generate_series(1,5000) s(i);
|
|
|
|
CREATE STATISTICS mcv_lists_arrays_stats (mcv) ON a, b, c
|
|
|
|
FROM mcv_lists_arrays;
|
|
|
|
ANALYZE mcv_lists_arrays;
|
|
|
|
-- mcv with bool
|
|
|
|
CREATE TABLE mcv_lists_bool (
|
|
|
|
a BOOL,
|
|
|
|
b BOOL,
|
|
|
|
c BOOL
|
|
|
|
);
|
|
|
|
INSERT INTO mcv_lists_bool (a, b, c)
|
|
|
|
SELECT
|
|
|
|
(mod(i,2) = 0), (mod(i,4) = 0), (mod(i,8) = 0)
|
|
|
|
FROM generate_series(1,10000) s(i);
|
|
|
|
ANALYZE mcv_lists_bool;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE a AND b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
156 | 1250
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
156 | 0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND NOT b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
469 | 0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND b AND NOT c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1094 | 0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CREATE STATISTICS mcv_lists_bool_stats (mcv) ON a, b, c
|
|
|
|
FROM mcv_lists_bool;
|
|
|
|
ANALYZE mcv_lists_bool;
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE a AND b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1250 | 1250
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND NOT b AND c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT * FROM check_estimated_rows('SELECT * FROM mcv_lists_bool WHERE NOT a AND b AND NOT c');
|
|
|
|
estimated | actual
|
|
|
|
-----------+--------
|
|
|
|
1 | 0
|
|
|
|
(1 row)
|
|
|
|
|
2019-06-23 19:50:08 +02:00
|
|
|
-- Permission tests. Users should not be able to see specific data values in
|
|
|
|
-- the extended statistics, if they lack permission to see those values in
|
|
|
|
-- the underlying table.
|
|
|
|
--
|
|
|
|
-- Currently this is only relevant for MCV stats.
|
|
|
|
CREATE TABLE priv_test_tbl (
|
|
|
|
a int,
|
|
|
|
b int
|
|
|
|
);
|
|
|
|
INSERT INTO priv_test_tbl
|
|
|
|
SELECT mod(i,5), mod(i,10) FROM generate_series(1,100) s(i);
|
|
|
|
CREATE STATISTICS priv_test_stats (mcv) ON a, b
|
|
|
|
FROM priv_test_tbl;
|
|
|
|
ANALYZE priv_test_tbl;
|
|
|
|
-- User with no access
|
|
|
|
CREATE USER regress_stats_user1;
|
|
|
|
SET SESSION AUTHORIZATION regress_stats_user1;
|
|
|
|
SELECT * FROM priv_test_tbl; -- Permission denied
|
|
|
|
ERROR: permission denied for table priv_test_tbl
|
|
|
|
-- Attempt to gain access using a leaky operator
|
|
|
|
CREATE FUNCTION op_leak(int, int) RETURNS bool
|
|
|
|
AS 'BEGIN RAISE NOTICE ''op_leak => %, %'', $1, $2; RETURN $1 < $2; END'
|
|
|
|
LANGUAGE plpgsql;
|
|
|
|
CREATE OPERATOR <<< (procedure = op_leak, leftarg = int, rightarg = int,
|
|
|
|
restrict = scalarltsel);
|
|
|
|
SELECT * FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied
|
|
|
|
ERROR: permission denied for table priv_test_tbl
|
|
|
|
DELETE FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Permission denied
|
|
|
|
ERROR: permission denied for table priv_test_tbl
|
|
|
|
-- Grant access via a security barrier view, but hide all data
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
CREATE VIEW priv_test_view WITH (security_barrier=true)
|
|
|
|
AS SELECT * FROM priv_test_tbl WHERE false;
|
|
|
|
GRANT SELECT, DELETE ON priv_test_view TO regress_stats_user1;
|
|
|
|
-- Should now have access via the view, but see nothing and leak nothing
|
|
|
|
SET SESSION AUTHORIZATION regress_stats_user1;
|
|
|
|
SELECT * FROM priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak
|
|
|
|
a | b
|
|
|
|
---+---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
DELETE FROM priv_test_view WHERE a <<< 0 AND b <<< 0; -- Should not leak
|
|
|
|
-- Grant table access, but hide all data with RLS
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
ALTER TABLE priv_test_tbl ENABLE ROW LEVEL SECURITY;
|
|
|
|
GRANT SELECT, DELETE ON priv_test_tbl TO regress_stats_user1;
|
|
|
|
-- Should now have direct table access, but see nothing and leak nothing
|
|
|
|
SET SESSION AUTHORIZATION regress_stats_user1;
|
|
|
|
SELECT * FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Should not leak
|
|
|
|
a | b
|
|
|
|
---+---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
DELETE FROM priv_test_tbl WHERE a <<< 0 AND b <<< 0; -- Should not leak
|
|
|
|
-- Tidy up
|
|
|
|
DROP OPERATOR <<< (int, int);
|
|
|
|
DROP FUNCTION op_leak(int, int);
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
DROP VIEW priv_test_view;
|
|
|
|
DROP TABLE priv_test_tbl;
|
2019-06-24 18:36:51 +02:00
|
|
|
DROP USER regress_stats_user1;
|