Penses-tu à une augmentation du cache côté matériel, OS ou postgres (si c'est possible bien sûr) ?
Merci à toi gleu.

Edit : je viens changer la valeur de effective_cache_size à 1/4 de ma ram (4 Go). Aucun changement flagrant sur la durée d'exécution des requêtes à froid.

En théorie gleu, les utilisateurs vont se connecter de partout vu que c'est une application mobile à destination du grand public ... Du coup, la plus part du temps le cache sera à froid comme tu le dis.
Les lignes sont en effet très petites.

Je ne sais pas si c'est ce que tu attends, mais voici les infos :

Alors que voudrait dire : psql:processing/db/2_db.sql:37206258: mémoire épuisée ? Sachant que la mémoire serveur n'est pas toute utilisée ... Je vais continuer mes investigations

Bonsoir,

Après un très fort crash du serveur en prod, les fichiers de journalisation de la version 8.4 ont été perdu ...

Existe t-il un moyen pour relancer la base sans eux ?
La version 9.4 a été installée, la restauration est à cette heure finie pour le problème de ce topic. Il me reste à poser l'INDEX btree. Cependant, avant toutes autres choses, j'aimerai pouvoir refaire partir le 8.4 ... rhaaa (j'ai bien peur que ce ne soit pas possible ...)

Edit : je mets la solution au problème de fichiers de journalisation corrompu

Cela ré-initialise ces fichiers, la base peut alors se relancer. (En tant qu'admin gleu, n'hésites pas à me demander d'ouvrir un autre topic pour poster ce bug particulier, si cela peut aider plus de monde).

Bonjour gleu et encore merci,

Ne pouvant pas changer mes ressources matériels pour le moment, l'idée du partitionnement m'était venue à la tête. Car une requête brute sur cette table (non partitionnée) donne un temps d'exécution de :

Brute = le première fois, la fois suivante, il organise (normal et heureusement) les données pour me les ressortir beaucoup plus rapide (avec les mêmes lat/lng).
Le soucis vient du fait que jamais ces lat/lng ne seront les mêmes. Elles sont rattachées à la localisation des utilisateurs, et les utilisateurs seront partout (app mobile).
Les données couvrent la surface terrestre, partitionner cette zone en sous-zones et créer une table pour chaque zone permettrait de diviser les temps d'exécution par autant non ? Imaginons 100 zones lat/lng, lors d'un select user, la requête ne sera effectuée que sur la table de la zone, donc sur 2,5 millions de lignes (250 millions / 100). Est-ce que le gain est trop faible par rapport à une unique table ? La création de 100 ou 1000 tables, une par zone, m'ennuie aussi, car je trouve ça un peu "sale" ... Mais plus d'1,5 s pour un select c'est long, très long. Même pour 250 millions de lignes ça me parait long avec un btree sur lat/lng ... Surtout après ta remarque "250 pauvres millions de lignes"
Que de questions, j'en conviens, désolé gleu

Toujours pour le même environnement, avec l'outil ANALYSE et EXPLAIN j'ai ceci :

// Temps=# explain analyse select * from last_run_025 where latitude = -26 and longitude = 359.75;
//  Index Scan using lat_lng_idx on last_run_025  (cost=0.00..918.66 rows=218 width=71) (actual time=0.050..1.284 rows=238 loops=1)
//    Index Cond: ((latitude = (-26)::double precision) AND (longitude = 359.75::double precision))
//  Total runtime: 1.340 ms

// Temps=# explain analyse select * from last_run_025 where latitude = -34 and longitude = 339.75;
//  Index Scan using lat_lng_idx on last_run_025  (cost=0.00..1859.32 rows=451 width=71) (actual time=0.058..1.115 rows=238 loops=1)
//    Index Cond: ((latitude = (-34)::double precision) AND (longitude = 339.75::double precision))
//  Total runtime: 1.162 ms

Sur ma table, j'ai un index btree(latitude, longitude).

Pourquoi je n'ai pas le même coût entre les deux requêtes ? Serait-il plus performant d'avoir une clé de hash (lat+lng, mais non unique du coup) et de l'indexer seule ?
Idem, ci-dessous (les deux requêtes n'ont jamais été effectuées auparavant) :

// Temps=# explain analyse select * from last_run_025 where latitude = -34 and longitude = 300.75;
//  Index Scan using lat_lng_idx on last_run_025  (cost=0.00..1224.16 rows=293 width=71) (actual time=12.852..1497.365 rows=238 loops=1)
//    Index Cond: ((latitude = (-34)::double precision) AND (longitude = 300.75::double precision))
//  Total runtime: 1497.595 ms

// Temps=# explain analyse select * from last_run_025 where latitude = -34 and longitude = 200.75;
//  Index Scan using lat_lng_idx on last_run_025  (cost=0.00..1742.74 rows=422 width=71) (actual time=16.308..1560.096 rows=238 loops=1)
//    Index Cond: ((latitude = (-34)::double precision) AND (longitude = 200.75::double precision))
//  Total runtime: 1560.307 ms

Pourquoi le coût diffère ? Pourquoi le temps d’exécution est-il aussi important d'un coup ? Il est alors assez difficile de mesurer les performances pour les améliorer ...
A raison de 250 millions de lignes indexées sur une seule table, je me demande le gain de performances à la spliter entre plusieurs tables en fonction des lat/lng ...

Merci pour vos futures réponses qui m'aident grandement !
Bonne fin de journée à tous.

Merci pour ta réponse gleu.
Mais du coup, quelle serait la meilleure solution ? Car je comptais utiliser les triggers pour spliter mes données automatiquement. Ce qui, par la suite, permettrait d'accélérer les vitesses d'accès.
J'avoue que je n'ai plus de solutions. Dans un monde "tout rose", serait-il possible d'écrire directement depuis le C++ les données en "format" postgres ? Ce qui éviterait l'écriture dans un fichier préalable pour ensuite les insérer dans la base. Mais est-ce que le gain sera intéressant ?
Pour te répondre anayrat, je ne peux pas changer mon environnement matériel

Merci à tous pour vos aides.

Merci rjuju pour ta réponse.
Lorsque tu dis "mais passer le paramètre fsync à on changera la donne", tu sous-entends quoi ? Que cela va ralentir le processus ?
Je vais voir pour faire plusieurs fichiers et les lancer parallèlement du coup.
Je suis toujours preneur de conseils et d'optimisation ! ;p

PS : n'y a t'il pas moyen (en C++) de sortir un format qui serait plus rapide à être inséré dans la base ?