あなたの仕様（プラスコメントの追加情報）を考えると、
- ギャップがほとんどない（または適度に少ない）数値ID列（整数）があります。
- 明らかに、書き込み操作はありません。
- ID列にはインデックスを付ける必要があります！主キーはうまく機能します。
以下のクエリでは、大きなテーブルの順次スキャンは必要ありません。インデックススキャンのみが必要です。
まず、メインクエリの見積もりを取得します。
SELECT count(*) AS ct -- optional
, min(id) AS min_id
, max(id) AS max_id
, max(id) - min(id) AS id_span
FROM big;
おそらく高価な部分はcount(*)（巨大なテーブルの場合）だけです。上記の仕様を考えると、それは必要ありません。見積もりは問題なく行われ、ほとんど無料で利用できます（詳細な説明はこちら）：
SELECT reltuples AS ct FROM pg_class WHERE oid = 'schema_name.big'::regclass;
限りctではありません多くのより小さいid_span、クエリは、他のアプローチをアウトパフォームします。
WITH params AS (
SELECT 1 AS min_id -- minimum id <= current min id
, 5100000 AS id_span -- rounded up. (max_id - min_id + buffer)
)
SELECT *
FROM (
SELECT p.min_id + trunc(random() * p.id_span)::integer AS id
FROM params p
,generate_series(1, 1100) g -- 1000 + buffer
GROUP BY 1 -- trim duplicates
) r
JOIN big USING (id)
LIMIT 1000; -- trim surplus
id空間で乱数を生成します。「ギャップが少ない」ため、取得する行の数に10％（ブランクを簡単にカバーするのに十分）を追加します。
それぞれidが偶然に複数回選択される可能性があるため（大きなidスペースでは非常にまれです）、生成された数値をグループ化（またはを使用DISTINCT）します。
idsを大きなテーブルに結合します。これは、インデックスが設定されていると非常に高速になります。
最後にid、だましや隙間で食べられなかった余剰分を取り除きます。すべての行は、選択される完全に等しいチャンスを持っています。
短縮版
このクエリを簡略化できます。上記のクエリのCTEは、教育目的のみです。
SELECT *
FROM (
SELECT DISTINCT 1 + trunc(random() * 5100000)::integer AS id
FROM generate_series(1, 1100) g
) r
JOIN big USING (id)
LIMIT 1000;
rCTEで絞り込む
特に、ギャップと見積もりについて確信が持てない場合。
WITH RECURSIVE random_pick AS (
SELECT *
FROM (
SELECT 1 + trunc(random() * 5100000)::int AS id
FROM generate_series(1, 1030) -- 1000 + few percent - adapt to your needs
LIMIT 1030 -- hint for query planner
) r
JOIN big b USING (id) -- eliminate miss
UNION -- eliminate dupe
SELECT b.*
FROM (
SELECT 1 + trunc(random() * 5100000)::int AS id
FROM random_pick r -- plus 3 percent - adapt to your needs
LIMIT 999 -- less than 1000, hint for query planner
) r
JOIN big b USING (id) -- eliminate miss
)
SELECT *
FROM random_pick
LIMIT 1000; -- actual limit
基本クエリで小さな余剰を処理できます。ギャップが多すぎて最初の反復で十分な行が見つからない場合、rCTEは再帰的な項で反復を続けます。IDスペースに比較的少ないギャップがまだ必要です。そうしないと、制限に達する前に再帰が空になる可能性があります。または、パフォーマンスを最適化する目的に反する十分に大きなバッファーで開始する必要があります。
重複はUNION、rCTEのによって排除されます。
アウターLIMITは、十分な行があるとすぐにCTEを停止します。
このクエリは、利用可能なインデックスを使用し、実際にランダムな行を生成し、制限を満たすまで停止しないように注意深く作成されています（再帰が実行されない限り）。あなたがそれを書き直すつもりなら、ここにいくつかの落とし穴があります。
関数にラップ
さまざまなパラメーターで繰り返し使用する場合：
CREATE OR REPLACE FUNCTION f_random_sample(_limit int = 1000, _gaps real = 1.03)
RETURNS SETOF big AS
$func$
DECLARE
_surplus int := _limit * _gaps;
_estimate int := ( -- get current estimate from system
SELECT c.reltuples * _gaps
FROM pg_class c
WHERE c.oid = 'big'::regclass);
BEGIN
RETURN QUERY
WITH RECURSIVE random_pick AS (
SELECT *
FROM (
SELECT 1 + trunc(random() * _estimate)::int
FROM generate_series(1, _surplus) g
LIMIT _surplus -- hint for query planner
) r (id)
JOIN big USING (id) -- eliminate misses
UNION -- eliminate dupes
SELECT *
FROM (
SELECT 1 + trunc(random() * _estimate)::int
FROM random_pick -- just to make it recursive
LIMIT _limit -- hint for query planner
) r (id)
JOIN big USING (id) -- eliminate misses
)
SELECT *
FROM random_pick
LIMIT _limit;
END
$func$ LANGUAGE plpgsql VOLATILE ROWS 1000;
コール：
SELECT * FROM f_random_sample();
SELECT * FROM f_random_sample(500, 1.05);
このジェネリックを任意のテーブルで機能するようにすることもできます。PK列の名前とテーブルをポリモーフィック型として使用しEXECUTEます。しかし、それはこの質問の範囲を超えています。見る：
可能な代替
要件で繰り返し呼び出しの同一セットが許可されている場合（繰り返し呼び出しについて話している場合）、具体化されたビューを検討します。上記のクエリを1回実行し、結果をテーブルに書き込みます。ユーザーは、驚くほどの速さで準ランダム選択を取得します。選択した間隔またはイベントでランダムピックを更新します。
nパーセンテージはどこですか。マニュアル：
BERNOULLIそしてSYSTEMサンプリング方法はそれぞれとして表さ試料テーブルの一部である単一の引数、受け入れ
0と100の間の割合。この引数には、任意のreal値の式を指定できます。
大胆な強調鉱山。それはだ非常に速いが、結果は正確にランダムではありません。再びマニュアル：
このSYSTEMメソッドはBERNOULLI、小さいサンプリング率が指定されている場合のメソッドよりも大幅に高速ですが、クラスタリング効果の結果として、ランダムでないテーブルのサンプルを返す場合があります。
返される行の数は大幅に異なる場合があります。この例では、およそ 1000行を取得します。
SELECT * FROM big TABLESAMPLE SYSTEM ((1000 * 100) / 5100000.0);
関連：
または、追加のモジュールtsm_system_rowsをインストールして、リクエストされた行の数を正確に取得し（十分な場合）、より便利な構文を許可します。
SELECT * FROM big TABLESAMPLE SYSTEM_ROWS(1000);
詳細については、Evanの回答を参照してください。
しかし、それはまだ完全にランダムではありません。