SELECT * à partir du tableau simple avec 50k enregistrements semble prendre 40 secondes

Question

Voici ma table:

CREATE TABLE public.logs (
    logid bigint NOT NULL DEFAULT nextval('applog_logid_seq'::regclass), 
    applicationname character varying(50), 
    loglevel character varying(10), 
    logmessage character varying(500), 
    stacktrace character varying(4096), 
    occurredon timestamp without time zone, 
    loggedon timestamp without time zone, 
    username character varying(50), 
    groupname character varying(50), 
    useragent character varying(512), 
    CONSTRAINT applog_pkey PRIMARY KEY (logid) 
); 

Quand je lance SELECT *... dessus, il faut 40 secondes pour revenir sur ma 50000 lignes machine locale. J'ai la même table sur une installation locale de SQL Server, et cela prend moins d'une seconde pour renvoyer la même quantité de données.

Je suis au milieu d'une évaluation de PostgreSQL pour notre nouvelle pile et c'est très préoccupant pour moi. Pourquoi je fais mal/pourquoi PostgreSQL est si lent?

Edit:

Voici ce que je reçois de EXPLAIN (BUFFERS, ANALYZE, TIMING OFF) SELECT * FROM public.logs:

Il semble donc que le serveur va exécuter ce dans environ 6 ms. Je suppose que cela signifie que tous les frais généraux sont dans pgAdmin III, mais comment SSMS peut-il le faire beaucoup plus rapidement?

Answer 1

Merci beaucoup pour l'aide de tout le monde me parle bas de la falaise :)

Je compose une application console app de nœud qui met mes préoccupations au lit. En fait, mon instance de Postres bat environ 50% de SQL Server (comme l'a souligné @Guillaume F.). Dans le même client voici les résultats:

Postres durée de requête (RDS): 7062ms

Postres (RDS) lignes retournées: 50000

Postgres durée de requête (locale): 1919ms

Postgres lignes (locales) sont retournés: 46154

MSSQL durée de requête (locale): 4681ms

lignes MSSQL (locales) sont retournés: 50000

est ici l'exemple d'application si quelqu'un est intéressé à reproduire mes résultats dans leur propre environnement:

'use strict'; 

let pgp = require('pg-promise')(); 
let db = pgp("postgres://username:password@server:5432/db"); 
let localdb = pgp("postgres://username:password@server:5432/db"); 
var mssql = require('mssql'); 

let start = new Date(); 
db.query('select * from logs').then((result) => { 
    console.log("Postres (RDS) query duration: " + (new Date() - start) + "ms"); 
    console.log("Postres (RDS) rows returned: " + result.length); 
    console.log(""); 

    let localstart = new Date(); 
    localdb.query('select * from logs').then((localresult) => { 
     console.log("Postgres (Local) query duration: " + (new Date() - localstart) + "ms"); 
     console.log("Postgres (Local) rows returned: " + localresult.length); 
     console.log(""); 

     var config = { 
      user: 'username', 
      password: 'password', 
      server: 'server', // You can use 'localhost\\instance' to connect to named instance 
      database: 'db' 
     }; 

     mssql.connect(config).then(function() { 

      // Query 
      let localMSSqlStart = new Date(); 
      new mssql.Request().query('select TOP 50000 * from dbo.AppLog ORDER BY 1 DESC').then(function (recordset) { 
       console.log("MSSQL (local) query duration: " + (new Date() - localMSSqlStart) + "ms"); 
       console.log("MSSQL (local) rows returned: " + result.length); 
       console.log(""); 
      }).catch(function (err) { 

       // ... query error checks 
       console.log("Problem querying MSSQL: " + err); 
      }); 
     }).catch(function (err) { 

      // ... connect error checks 
      console.log("Problem connecting to MSSQL: " + err); 
     }); 
    }); 
}); 

EDIT: (par pg-promise auteur)

Sur une note de côté, c'est juste pour montrer comment référencer PostgreSQL d'une manière plus civilisée:

let pgp = require('pg-promise')(); 
let db = pgp("postgres://username:password@server:5432/db"); 
let localdb = pgp("postgres://username:password@server:5432/db"); 

db.result('select * from logs') 
    .then(r => { 
     console.log("Postres (RDS) rows returned:", r.rows.length); 
     console.log("Postres (RDS) query duration:", r.duration + 'ms\n'); 
     return localdb.result('select * from logs') 
      .then(r => { 
       console.log("Postgres (Local) rows returned:", r.rows.length); 
       console.log("Postgres (Local) query duration:", r.duration + 'ms\n'); 
      }) 
    }) 
    .catch(error=> { 
     console.log(error); 
    }); 

L'avantage de l'utilisation de la méthode result pour les tests de performances est que pg-promise étend automatiquement le Result avec la propriété duration.

Answer 2

Comme nous le suspectons, et comme nous pouvons le voir à partir de la sortie EXPLAIN, presque aucun temps n'est passé sur le serveur, mais pour le transfert (latence du réseau) et le rendu de la sortie. Nous voyons 7 ms dans la sortie EXPLAIN que vous avez ajouté à la question.

Le rendu de grandes quantités de texte dans pgAdmin III n'est pas très rapide. Deux conseils:

1. La plupart du temps, vous n'avez pas besoin de voir tout le contenu des colonnes énormes. Pour accélérer les choses, vous pouvez définir un nombre maximum de caractères d'affichage dans pgAdmin III. Mais ne vous trompez pas si vous ne voyez le fragment avant de longues chaînes:

   • Why are query results shortened in pgAdmin 1.18.1?

2. pgAdmin 4 beta 2 est en (24/06/2016). Pas encore publié, mais comme il s'agit d'une performance de réécriture complète peut être sensiblement différente. More on project's site.