Puede examinar y comparar el plan de ejecución de ambos usando

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

Una prueba rápida en una mesa grande¹ muestra, que el ORDER BY primero ordena la tabla completa y luego elige los primeros 1000 elementos. Ordenar una tabla grande no solo lee esa tabla, sino que también implica leer y escribir archivos temporales. El where random() < 0.1 solo escanea la tabla completa una vez.

Para tablas grandes esto podría no ser lo que desea, ya que incluso un análisis completo de la tabla podría tardar mucho.

Un tercero la propuesta sería

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

Este detiene el análisis de la tabla tan pronto como se han encontrado 1000 filas y, por lo tanto, regresa antes. Por supuesto, esto empaña la aleatoriedad un poco, pero tal vez esto es lo suficientemente bueno en su caso.

Edit: Además de estas consideraciones, puede consultar las preguntas ya hechas para esto. Usando la consulta [postgresql] random devuelve bastantes hits.

• selección rápida de filas aleatorias en Postgres
• Cómo recuperar ¿filas de datos aleatorias de una tabla de PostgreSQL?
• postgres: obtener entradas aleatorias de la tabla-demasiado lento

Y un artículo vinculado de depez que describe varios enfoques más:

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

¹ "grande", como en "la tabla no caben en la memoria".

Postgresql orden por random(), seleccionar filas en orden aleatorio:

select your_columns from your_table ORDER BY random()

Postgresql orden por random () con un distinto:

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

Orden de Postgresql por límite aleatorio de una fila:

select your_columns from your_table ORDER BY random() limit 1

Comenzando con PostgreSQL 9.5, hay una nueva sintaxis dedicada a obtener elementos aleatorios de una tabla:

SELECT * FROM mytable TABLESAMPLE SYSTEM (5);

Este ejemplo le dará el 5% de los elementos de mytable.

Ver más explicación en esta entrada del blog: http://www.postgresql.org/docs/current/static/sql-select.html

El que tiene el ORDEN POR va a ser el más lento.

select * from table where random() < 0.01; va registro por registro, y decide filtrarlo aleatoriamente o no. Esto va a ser O(N) porque solo necesita verificar cada registro una vez.

select * from table order by random() limit 1000; va a ordenar toda la mesa, luego elegir los primeros 1000. Aparte de cualquier magia vudú detrás de las escenas, el orden por es O(N * log N).

La desventaja de la random() < 0.01 es que obtendrá un número variable de registros de salida.

Nota, hay un mejor manera de barajar un conjunto de datos que ordenar por azar: El Fisher-Yates Barajar, que se ejecuta en O(N). Sin embargo, implementar el shuffle en SQL suena como un gran desafío.

Aquí hay una decisión que funciona para mí. Supongo que es muy simple de entender y ejecutar.

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 sabes cuántas filas quieres, echa un vistazo tsm_system_rows.

Tsm_system_rows

El módulo proporciona el método de muestreo de tablas SYSTEM_ROWS, que se puede utilizar en la cláusula TABLES-SAMPLE de un comando SELECT.

Este método de muestreo de tabla acepta un solo argumento entero que es el número máximo de filas a leer. La muestra resultante siempre contendrá exactamente esas filas, a menos que la tabla no contenga suficientes filas, en las que caso se selecciona toda la tabla. Al igual que el método de muestreo del SISTEMA integrado, SYSTEM_ROWS realiza muestreo a nivel de bloque, de modo que la muestra no es completamente aleatoria, sino que puede estar sujeta a efectos de agrupación, especialmente si solo se solicita un pequeño número de filas.

Primero instale la extensión

CREATE EXTENSION tsm_system_rows;

Entonces su consulta,

SELECT *
FROM table
TABLESAMPLE SYSTEM_ROWS(1000);

Si desea una sola fila, puede usar un offset calculado derivado de count.

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

Una variación de la vista materializada "Posible alternativa" esbozada por Erwin Brandstetter es posible.

Digamos, por ejemplo, que no desea duplicados en los valores aleatorios que se devuelven. Por lo tanto, deberá establecer un valor booleano en la tabla principal que contiene su conjunto de valores (no aleatorios).

Suponiendo que esta es la tabla de entrada:

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

Rellene la tabla ID_VALUES según sea necesario. Luego, como lo describe Erwin, cree una vista materializada que aleatoriza la tabla ID_VALUES una vez:

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

Tenga en cuenta que la vista materializada no contiene la columna utilizada, porque esto se desactualizará rápidamente. Tampoco es necesario que la vista contenga otras columnas que puedan estar en la tabla id_values.

Para obtener (y "consumir") valores aleatorios, utilice un UPDATE-RETURNING en id_values, seleccionando id_values de id_values_randomized con una combinación, y aplicando los criterios deseados para obtener solo posibilidades relevantes. Para ejemplo:

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;

Cambie LIMIT según sea necesario if si solo necesita un valor aleatorio a la vez, cambie LIMIT a 1.

Con los índices adecuados en id_values, creo que el RETORNO de ACTUALIZACIÓN debería ejecutarse muy rápidamente con poca carga. Devuelve valores aleatorios con una base de datos ida y vuelta. Los criterios para las filas" elegibles " pueden ser tan complejos como sea necesario. Se pueden agregar nuevas filas a la tabla id_values en cualquier momento, y serán accesibles para la aplicación tan pronto como el la vista materializada se actualiza (lo que probablemente se puede ejecutar en un momento fuera de las horas punta). La creación y actualización de la vista materializada será lenta, pero solo necesita ejecutarse cuando se agreguen nuevos ID a la tabla id_values.

Agregue una columna llamada r con el tipo serial. Index r.

Supongamos que tenemos 200.000 filas, vamos a generar un número aleatorio n, donde 0 n

Seleccione filas con r > n, ordénelas ASC y seleccione la más pequeña.

Código:

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);

El código se explica por sí mismo. La subconsulta en el medio se utiliza para estimar rápidamente los recuentos de filas de la tabla desde https://stackoverflow.com/a/7945274/1271094 .

En aplicación nivel necesita ejecutar la instrucción de nuevo si n > el número de filas o necesita seleccionar varias filas.

Sé que llego un poco tarde a la fiesta, pero acabo de encontrar esta increíble herramienta llamada pg_sample :

pg_sample - extraiga un pequeño conjunto de datos de muestra de una base de datos PostgreSQL más grande mientras mantiene la integridad referencial.

Probé esto con una base de datos de filas de 350M y fue muy rápido, no sé sobre la aleatoriedad .

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