vous pouvez examiner et comparer le plan d'exécution des deux en utilisant

EXPLAIN select * from table where random() < 0.01;
EXPLAIN select * from table order by random() limit 1000;

un test rapide sur une grande table ¹ montre, que le ORDER BY trie d'abord la table complète et choisit ensuite les 1000 premiers articles. Le tri d'une grande table ne se limite pas à lire cette table, mais implique également la lecture et l'écriture de fichiers temporaires. Le where random() < 0.1 ne scanne la table complète qu'une seule fois.

pour les grandes tables ce n'est peut-être pas ce que vous voulez que même un scan complet de table pourrait prendre trop de temps.

une troisième proposition serait

select * from table where random() < 0.01 limit 1000;

celui-ci arrête le scan de table dès que 1000 lignes ont été trouvées et retourne donc plus tôt. Bien sûr, cela réduit un peu le caractère aléatoire, mais c'est peut-être suffisant dans votre cas.

Edit: en plus de ces considérations, vous pouvez vérifier les questions déjà posées pour cela. En utilisant la requête [postgresql] random renvoie pas mal de résultats.

• rapide aléatoire de la sélection d'une ligne dans Postgres
• comment extraire des lignes de données aléatoires d'une table postgreSQL?
• postgres: obtenir des entrées aléatoires de la table - trop lent

et un article de depez décrivant plusieurs autres approches:

• http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row /

¹ "large" comme dans "la table complète ne rentrera pas dans la mémoire".

postgresql ordre aléatoire(), sélectionner des lignes dans un ordre aléatoire:

select your_columns from your_table ORDER BY random()

postgresql ordre aléatoire() avec une nette:

select * from 
  (select distinct your_columns from your_table) table_alias
ORDER BY random()

postgresql ordre par hasard, à la limite une seule ligne:

select your_columns from your_table ORDER BY random() limit 1

à partir de PostgreSQL 9.5, il y a une nouvelle syntaxe dédiée à l'obtention d'éléments aléatoires à partir d'une table:

SELECT * FROM mytable TABLESAMPLE SYSTEM (5);

cet exemple vous donnera 5% des éléments de mytable .

voir plus d'explications sur ce billet de blog: http://www.postgresql.org/docs/current/static/sql-select.html

celui qui commande va être le plus lent.

select * from table where random() < 0.01; passe enregistrement par enregistrement, et décide de le filtrer au hasard ou non. Cela va être O(N) parce qu'il a seulement besoin de vérifier chaque enregistrement une fois.

select * from table order by random() limit 1000; va trier la table entière, puis choisir le premier 1000. En dehors de toute magie vaudou dans les coulisses, l'ordre est O(N * log N) .

L'inconvénient de la random() < 0.01 un est que vous obtiendrez un nombre variable d'enregistrements de sortie.

Note, il y a une meilleure façon de mélanger un ensemble de données que de les trier au hasard: The Fisher-Yates Shuffle , qui s'exécute en O(N) . Mettre en œuvre le shuffle en SQL semble être tout à fait le défi, cependant.

Voici une décision qui marche pour moi. Je suppose que c'est très simple à comprendre et à exécuter.

SELECT 
  field_1, 
  field_2, 
  field_2, 
  random() as ordering
FROM 
  big_table
WHERE 
  some_conditions
ORDER BY
  ordering 
LIMIT 1000;

select * from table order by random() limit 1000;

si vous savez combien de lignes vous voulez, Vérifiez tsm_system_rows .

tsm_system_rows

module fournit la table method sampling method SYSTEM_ROWS, qui peut être utilisé dans la clause TABLESAMPLE d'une commande SELECT.

cette méthode d'échantillonnage de tableau accepte un seul argument entier qui est le nombre maximum de lignes à lire. Le l'échantillon résultant contiendra toujours exactement autant de lignes, à moins que la table ne contienne pas assez de lignes, auquel cas la table entière est sélectionnée. comme la méthode d'échantillonnage intégrée au système, SYSTEM_ROWS effectue un échantillonnage au niveau du bloc, de sorte que l'échantillon n'est pas complètement aléatoire, mais peut être sujet à des effets de regroupement, surtout si seulement un petit nombre de lignes sont demandées.

première installation de l'extension

CREATE EXTENSION tsm_system_rows;

puis votre requête,

SELECT *
FROM table
TABLESAMPLE SYSTEM_ROWS(1000);

si vous voulez une seule rangée, vous pouvez utiliser un calcul offset dérivé de count .

select * from table_name limit 1
offset floor(random() * (select count(*) from table_name));

une variante de la vue matérialisée" alternative Possible " esquissée par Erwin Brandstetter est possible.

Dire, par exemple, que vous ne voulez pas de doublons dans les randomisés valeurs retournées. Donc, vous devez définir une valeur booléenne sur la table primaire contenant votre (non randomisée) ensemble de valeurs.

en supposant que c'est la table d'entrée:

id_values  id  |   used
           ----+--------
           1   |   FALSE
           2   |   FALSE
           3   |   FALSE
           4   |   FALSE
           5   |   FALSE
           ...

peupler le Tableau ID_VALUES selon les besoins. Ensuite, comme décrit par Erwin, créer une vue matérialisée qui randomise la ID_VALUES table once:

CREATE MATERIALIZED VIEW id_values_randomized AS
  SELECT id
  FROM id_values
  ORDER BY random();

notez que la vue matérialisée ne contient pas la colonne utilisée, car celle-ci deviendra rapidement périmée. Il n'est pas non plus nécessaire que la vue contienne d'autres colonnes pouvant figurer dans le tableau id_values .

pour obtenir (et" consommer") des valeurs aléatoires, utilisez une mise à jour-retour sur id_values , sélectionner id_values de id_values_randomized avec une jointure, et appliquer les critères souhaités pour obtenir seulement les possibilités pertinentes. Par exemple:

UPDATE id_values
SET used = TRUE
WHERE id_values.id IN 
  (SELECT i.id
    FROM id_values_randomized r INNER JOIN id_values i ON i.id = r.id
    WHERE (NOT i.used)
    LIMIT 5)
RETURNING id;

modifier LIMIT au besoin -- si vous n'avez besoin que d'une valeur aléatoire à la fois, remplacer LIMIT par 1 .

avec les index appropriés sur id_values , je crois que la mise à jour-retour devrait s'exécuter très rapidement avec peu de charge. Il retourne randomisés valeurs base de données de l'aller-retour. Les critères pour les rangées "admissibles" peuvent être aussi complexes que requis. Les nouvelles lignes peuvent être ajoutées à la id_values table à tout moment, et ils auront accès à l'application dès que la vue matérialisée est actualisé (qui peut être exécuté à une période creuse). La création et le rafraîchissement de la vue matérialisée seront lents, mais ils ne doivent être exécutés que lorsque de nouvelles id sont ajoutées à la table id_values .

ajouter une colonne intitulée r avec le type serial . L'indice r .

supposons que nous avons 200.000 lignes, nous allons générer un nombre aléatoire n , où 0 < n <= 200, 000.

sélectionnez les lignes avec r > n , triez-les ASC et sélectionnez la plus petite.

Code:

select * from YOUR_TABLE 
where r > (
    select (
        select reltuples::bigint AS estimate
        from   pg_class
        where  oid = 'public.YOUR_TABLE'::regclass) * random()
    )
order by r asc limit(1);

le code est explicite. Le subquery au milieu est utilisé pour estimer rapidement le nombre de lignes de la table à partir de https://stackoverflow.com/a/7945274/1271094 .

au niveau de l'application, vous devez exécuter l'instruction à nouveau si n > le nombre de lignes ou besoin de sélectionner plusieurs lignes.

je sais que je suis un peu en retard à la fête, mais je viens de trouver cet outil génial appelé pg_sample :

pg_sample - extraire un petit échantillon de données d'une base de données PostgreSQL plus grande tout en maintenant l'intégrité référentielle.

j'ai essayé avec une base de données de 350 m et c'était vraiment rapide, Je ne sais pas à propos du randomness .

./pg_sample --limit="small_table = *" --limit="large_table = 100000" -U postgres source_db | psql -U postgres target_db