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は確認する手元にはありません。