PostgresとVoid

Postgresqlの機能に出会いましたが、これはおもしろそうに思えました。 「ボタンアコーディオン」-敬意を表して、私はPostgresで数年間働いてきましたが、まだそのようなことに遭遇していません。

select; フィールド、テーブル、および条件を指定しないと、単一の行が返されます。 ただし、この行にはフィールドがありません。

 => select; -- (1 row) 

比較のために：

 => select null; ?column? ---------- (1 row) => select null where 0=1; ?column? ---------- (0 rows) 

しかし、そのような「空の」クエリからテーブルを作成できますか？ ボーダーのないテーブル。

はい、お願いします：

 => create table t as select; SELECT 1 => \d+ t Table "t" Column | Type | Modifiers | Storage | Stats target | Description --------+------+-----------+---------+--------------+------------- => select * from t; -- (1 row) 

挿入できますか？
簡単：

 => insert into t select; INSERT 0 1 => insert into t select; INSERT 0 1 => select * from t; -- (3 rows) => select count(*) from t; count ------- 3 

もっと！

 => insert into t select from generate_series(1,1000000); INSERT 0 1000000 

Postgresqlがそのようなテーブルをスキャンするのだろうか？

 => explain analyze select * from t; QUERY PLAN ------------------------------------------------------------------------------------------------------------ Seq Scan on t (cost=0.00..13438.67 rows=1000167 width=0) (actual time=0.018..96.389 rows=1000003 loops=1) Planning time: 0.024 ms Execution time: 134.654 ms (3 rows) 

はい、正直にスキャンします。 100ミリ秒以上-非常に顕著な時間です。
さて、すべてが公平であることを確認するために、私たちの非常に便利なテーブルがどれだけのスペースを取るかを見てみましょう：

 => select pg_size_pretty(pg_total_relation_size('t')); pg_size_pretty ---------------- 27 MB (1 row) 

つまり、テーブルがあり、ディスクスペースを占有し、異なるサービスデータがブロックに格納されますが、フィールドが存在しないという事実が時々発生します！

 => select t.xmin, t.ctid from t limit 10; xmin | ctid ---------+-------- 1029645 | (0,1) 1029647 | (0,2) 1029648 | (0,3) 1029649 | (0,4) 1029649 | (0,5) 1029649 | (0,6) 1029649 | (0,7) 1029649 | (0,8) 1029649 | (0,9) 1029649 | (0,10) (10 rows) 

このようなテーブルが必要になる理由は考えていませんでした。 しかし、機会があり、それは良いことです！
Postgresql 9.6を使用しています。 下のバージョンで後述するように、これは機能しません。 9.3では、 syntax error生成されsyntax error 。 9.4、9.5は確認する手元にはありません。