Hi hackers,
Hi hackers,
Now we can create a table with a virtual generated column, but
when a condition in WHERE clause contains virtual generated column,
estimated rows are not correct since no statistics on this is
collectef.
[Ex.1]
test=# CREATE TABLE t (i int, v int GENERATED ALWAYS AS (i+1) VIRTUAL);
CREATE TABLE
test=# INSERT INTO t SELECT generate_series(1,1000);
INSERT 0 1000
test=# INSERT INTO t SELECT 1 FROM generate_series(1,1000);
INSERT 0 1000
test=# EXPLAIN ANALYZE SELECT * FROM t WHERE v = 2;
QUERY PLAN
--------------------------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..36.02 rows=9 width=8) (actual time=0.093..3.059 rows=1001.00 loops=1)
Filter: ((i + 1) = 2)
Rows Removed by Filter: 999
Buffers: shared hit=9
Planning:
Buffers: shared hit=26
Planning Time: 1.142 ms
Execution Time: 3.434 ms
(8 rows)
Therefore, I would like to allow to collect statistics on virtual enerated columns.
I think there are at least three approaches for this.
(1) Allow the normal ANALYZE to collect statistics on virtual generated columns
ANALYZE expands virtual generated columns' expression, and collects statistics
on evaluated values. In this approach, the statistics on virtual generated columns
are collected in default, but ANALYZE on the table would become a bit expensive.
(2) Allow to create an index on virtual generated column
This is proposed in [1]. This proposal itself would be useful, I believe it is better
to provide a way to collect statistics without cost of creating an index.
[1] https://www.postgresql.org/message-id/flat/CACJufxGao-cypdNhifHAdt8jHfK6-HX=tRBovBkgRuxw063GaA@mail.gmail.com
(3) Allow to create extended statistics on virtual generated columns
In this approach, ANALYZE processes virtual generated columns only if corresponding
extended statistics are defined. Although we can create extended statistics on
expressions of virtual generated columns even in the current implementation, this enables
that users to create a useful statistics this just by specifying a column name without
specifying complex expression.
I can also think of two variations for this approach.
(3a)
At the timing when an extended statistics is created, virtual generated columns are
expanded, and the statistics is defined on this expression.
(3b)
At the timing when an extended statistics is created, virtual generated columns are
NOT expanded. The statistics is defined on the virtual generated column itself and,
the expression is expanded when ANALYZE processes the extended statistics.
I've attached a draft patch based on (3a). However, if it is possible we could change
the definition of generated columns in future (as proposed in [2]), (3b) might be preferred.
[2] https://www.postgresql.org/message-id/flat/CACJufxH3VETr7orF5rW29GnDk3n1wWbOE3WdkHYd3iPGrQ9E_A@mail.gmail.com
Here is an example of how the patch works.
[Ex.2]
test=# CREATE STATISTICS exstat ON v FROM t;
CREATE STATISTICS
test=# ANALYZE t;
ANALYZE
test=# EXPLAIN ANALYZE SELECT * FROM t WHERE v = 2;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..41.50 rows=1001 width=8) (actual time=0.067..2.422 rows=1001.00 loops=1)
Filter: ((i + 1) = 2)
Rows Removed by Filter: 999
Buffers: shared hit=9
Planning:
Buffers: shared hit=14
Planning Time: 0.785 ms
Execution Time: 2.744 ms
(8 rows)
What do you think of this? Which approach of (1), (3a), or (3b) is good?
Or, completely different approach is better?
With your feedback, I would like to progress or rework the patch.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
