Comment lire toutes les lignes de table immense?

Utilisation un CURSEUR dans PostgreSQL ou laissez JDBC pilote de gérer cela pour vous.

LIMIT et OFFSET obtiendra lente lors de la manipulation de jeux de données volumineux.

Il s'avère donc que le noeud du problème est que par défaut, Postgres commence dans "autoCommit" de mode, et aussi il a besoin de/utilise les curseurs pour être en mesure de "page" par le biais de données (ex: lire le premier 10K résultats, puis la suivante, puis la suivante), cependant les curseurs ne peut exister qu'au sein d'une transaction. Donc la valeur par défaut est de lire toutes les lignes, toujours, dans la RAM, et puis laissez votre programme pour lancer le traitement "la première ligne, puis la deuxième" après qu'il ait tous arrivé, pour deux raisons, il n'est pas dans une transaction (afin de curseurs ne fonctionnent pas), et aussi une taille d'extraction n'a pas été définie.

Alors, comment les psql outil de ligne de commande atteint par lot réponse (son FETCH_COUNT réglage) pour les requêtes, est de "wrap" de ses requêtes de sélection au sein d'opérations à court terme (si une transaction n'est pas encore ouverte), de sorte que les curseurs peuvent travailler. Vous pouvez faire quelque chose comme ça aussi avec JDBC:

  static void readLargeQueryInChunksJdbcWay(Connection conn, String originalQuery, int fetchCount, ConsumerWithException<ResultSet, SQLException> consumer) throws SQLException {
    boolean originalAutoCommit = conn.getAutoCommit();
    if (originalAutoCommit) {
      conn.setAutoCommit(false); //start temp transaction
    }
    try (Statement statement = conn.createStatement()) {
      statement.setFetchSize(fetchCount);
      ResultSet rs = statement.executeQuery(originalQuery);
      while (rs.next()) {
        consumer.accept(rs); //or just do you work here
      }
    } finally {
      if (originalAutoCommit) {
        conn.setAutoCommit(true); //reset it, also ends (commits) temp transaction
      }
    }
  }
  @FunctionalInterface
  public interface ConsumerWithException<T, E extends Exception> {
    void accept(T t) throws E;
  }

Cela donne l'avantage de nécessiter moins de RAM, et, dans mes résultats, semblait courir ensemble plus rapidement, même si vous n'avez pas besoin pour économiser de la RAM. Bizarre. Il donne également l'avantage que votre traitement de première ligne "démarre plus vite" (puisque le processus d'une page à la fois).

Et voici comment le faire de la "raw postgres curseur" ainsi, le long avec plein de démonstration code, bien que dans mes expériences, il semblait JDBC façon, ci-dessus, a été légèrement plus rapide pour quelque raison que ce soit.

Une autre option serait d'avoir autoCommit mode off, partout, si vous avez encore de toujours spécifier manuellement un fetchSize pour chaque nouvelle Déclaration (ou vous pouvez définir une valeur par défaut taille de l'extraction dans la chaîne d'URL).

Je l'ai fait comme ci-dessous. Pas le meilleur moyen je pense, mais ça fonctionne 🙂

    Connection c = DriverManager.getConnection("jdbc:postgresql://....");
    PreparedStatement s = c.prepareStatement("select * from " + tabName + " where id > ? order by id");
    s.setMaxRows(100);
    int lastId = 0;
    for (;;) {
        s.setInt(1, lastId);
        ResultSet rs = s.executeQuery();

        int lastIdBefore = lastId;
        while (rs.next()) {
            lastId = Integer.parseInt(rs.getObject(1).toString());
            //...
        }

        if (lastIdBefore == lastId) {
            break;
        }
    }