Oula... là je suis perdu !

Pourquoi le fait que Slony n'interdise pas les modifications de schéma sur les tables non répliquées va aider mon outil de BI ?
On ne peut pas ajouter d'index à une table répliquée par Postgres lui-même ?
C'est ces deux points qui vont font préférer Slony à Postgres+Pgpool dans mon cas ?

Complexe à mettre en oeuvre, moins mature.. je passe mon chemin !

Bonsoir Guillaume,

Question 1 : dimensionnement dans le cas d'un noeud unique ?

Oui j'avoue avoir été léger en détails. La vérité est que la volumétrie est encore hypothétique.

Partons sur une table unique, une trentaine de champs pour 1000 octets au total (taille des données brutes) : un timestamp, une dizaines de compteurs (qu'on veut grapher), quelques chaines de caractères sur lesquelles on va filtrer. 5 index sur les colonnes de filtre.

En écriture :
- une centaine de clients faisant des INSERT, disons un toutes les dix secondes, en permanence, 24/7
En lecture :
- un client unique (l'outil de BI) qui viendrait faire ses requêtes deux à trois fois par jour pour générer un dashboard. Je n'ai pas regardé la complexité des requêtes générés par Tableau.

J'ai constaté que Postgres n'utilisait qu'un seul processeur, ce qui me semble sous-optimal. Donc finalement ca rend ma question stupide en réalité, non ?

Question 3 :
cf la question 1

Question 4 : GreenPlum & Co
D'expérience, savez vous à quelle volumétrie on peut s'y intéresser (plutot 100Go, 1Po et +) ? Grossièrement bien sûr.

J'espère avoir été plus précis cette fois. Encore merci de votre aide !

Je vois .. si effectivement en lisant la séquence BEGIN/COMMIT/BEGIN/COMMIT on peut envisager que la séquence réelle était BEGIN/BEGIN/COMMIT/COMMIT ca change tout ! Dommage que l'ordre ne soit pas fiable...

Je vais essayer ceci : http://www.postgresql.org/docs/current/ … RT-EXAMPLE, plutôt confiant !

Merci Guillaume !

Oh mais je commence à mettre les choses ensembles... J'ignorais l'existence de la syntaxe FETCH FORWARD, et donc j'utilisais un offset (celui sur lequel porte votre question!) pour récupérer "les 1000 suivantes", puis "encore les 1000 suivantes".
Si je comprends bien, le fait de passer une tableau de 1000 ne suffit pas à indiquer à ECPG qu'il faut fetcher par plus que 1 à chaque FETCH ?

L'utilisation du FORWARD dans le FETCH et l'élimination de l'offset devenu superflu divisent par 6 le temps d'exécution. C'est déjà plus acceptable. A l'occasion je refais un benchmark avec psql pour savoir plus précisemment où on en est.

Marc, encore mille mercis pour votre aide et votre patience !

SC

Non, j'avais un doute sur le traitement des données après réception, donc j'ai chronométrer, puis fini par supprimer les traitements autres que la pure récupération. Il n'y a guere plus que du code touchant de près à Postgres.
Le code résultant ressemble à celui indiqué ci-dessous.

/*
*
*/
int DBGet_AllItem ( long id_customer , long item_type , long item_id , long endDate , long startDate ) {

EXEC SQL BEGIN DECLARE SECTION;
long            pg_id_item_grp;
long            pg_id_item;
long            pg_id_customer;
long            pg_item_type;
long            pg_startDate;
long            pg_endDate;
EXEC SQL END DECLARE SECTION;

int             sqlcode                 = 0;

        /* A few inits */
        pg_id_customer = id_customer;
        pg_endDate = endDate;
        pg_startDate = startDate;
        pg_item_type = item_type;
        pg_id_item = item_id;
        
        EXEC SQL DECLARE cur_allitem CURSOR FOR
                                SELECT                  item_groups.id_item_grp,
                                                        item_groups.id_customer_item_grp,
                                                        id_item,
                                                        type_item
                                FROM    ( SELECT id_item_grp, id_customer_item_grp
                                                        FROM item_grp
                                                        WHERE   date_item_grp >= :pg_startDate
                                                        AND date_item_grp <= :pg_endDate
                                                        AND ( id_customer_item_grp = :pg_id_customer )
                                                        AND ( id_item_grp = :pg_id_item_grp OR :pg_id_item_grp = -1 )
                                                        ORDER BY        date_item_grp DESC , id_item_grp DESC
                                        ) AS item_groups
                                INNER JOIN item ON
                                                        ( id_item_grp = id_item_grp_item
                                                        AND ( type_item = :pg_item_type OR :pg_item_type = -1 ) )
                                ORDER BY        id_item_grp DESC , id_item DESC , type_item ASC;

        EXEC SQL        OPEN cur_allitem;
        if ( sqlca.sqlcode != ECPG_NO_ERROR ) {
                return ( sqlca.sqlcode );
        }

        while ( sqlca.sqlcode == ECPG_NO_ERROR ) {
                EXEC SQL        FETCH   cur_allitem
                                        INTO        :pg_id_item_grp, :pg_id_customer , :pg_id_item , :pg_type_item;
                if ( sqlca.sqlcode == ECPG_NO_ERROR ) {
                    // Aucun traitement ici en vue de ces tests de perf
                }
                else if ( sqlca.sqlcode == ECPG_NOT_FOUND ) {
                        break;
                }
                else {
                        sqlcode = sqlca.sqlcode;
                        EXEC SQL CLOSE cur_allitem;
                        if ( sqlca.sqlcode != ECPG_NO_ERROR ) {
                              return ( sqlca.sqlcode );
                        }
                        return ( sqlcode );
                }
        }

        EXEC SQL CLOSE cur_allitem;
        if ( sqlca.sqlcode != ECPG_NO_ERROR ) {
                return ( sqlca.sqlcode );
        }

        return ( ECPG_NO_ERROR );
}

J'ai quelque peu simplifié le code pour le rendre plus lisible.

Bonjour Marc,

Il me manque une info pour pouvoir répondre à cette question : j'imagine que l'appel a \set dans psql a une portée qui se limite uniquement au process psql en question, et n'est pas un paramètre global de postgresql. La preuve, je relance psql, et la variable n'est pas settée.

Si je comprends bien votre question, je devrais passer l'équivalent d'une telle commande en SQL embarqué dans mon code. Comment faire ? Je sèche !

Merci encore !

Oui effectivement, je suis en 8.4.

Apres passage de cursor_tuple_fraction à 1, le tout premier SELECT a pris environ 1400ms (peut etre parce que j'ai pris la base un peu à froid), tous les essais suivants seulement environ 40ms.
J'ai essayé ensuite d'unset cursor_tuple_fraction, les essais suivants ne sont pas spécialement plus longs que 40ms.
J'ai repassé cursor_tuple_fraction à 1, les temps de requetage oscillent tous autour de 40 ms.

D'autres idées ?

Bonjour Marc,

Avec psql, un fetch ligne par ligne (avec \set FETCH_COUNT 1) en moyenne coute 68ms pour fetcher l'ensemble des 1740 lignes, avec un fetch 1000 par 1000, la moyenne redescend a 60ms.

Avec mon code (tenez-vous bien), avec un fetch ligne par ligne (donc sans utilisation de tableaux alloués statiquement), je m'en sors avec 1400ms en moyenne. Et grosso modo 600ms avec des tableaux alloués statiquement et sans FETCH mais des SELECT avec un offset +1000 pour chaque SELECT.

Très étrange aussi : si je me contente d'un COUNT sur la requete plutot que de fetcher le résultat, j'en suis deja a 78ms en moyenne... Le meme count sur psql tourne autour de 50ms. Le cout du COUNT ne me choque pas (j'en ai absolument besoin, et d'une manière précise), mais c'est le fait qu'il soit presque 50% plus élevé que par psql alors que le volume de données transférées est j'imagine très faible.

La durée indiquée par psql (eg. "LOG:  duration: 50.639 ms") indique-t'il le temps complet de récupération de l'intégralité des lignes résultat, ou le temps jusqu'à la completion du premier FETCH partiel ( de FETCH_COUNT lignes donc).

psql utilise la lib libpq non ? Ca vaudrait le coup que je compare avec ou pas ?

Merci encore !

Oh que oui, c'est flagrant. C'est infiniment moins verbeux en fetchant 1000 par 1000.

Non, il ne s'agit pas d'une requête préparée, je la passe avec des variables hote directement comme ceci :

EXEC SQL
SELECT <les colonnes qui vont bien>
INTO                   <mes variables :pg_ qui vont bien>
FROM    ( SELECT <ce qu'il faut> FROM <la table>
                                WHERE  <les clauses qui vont bien>
                                ORDER BY        <comme il faut>
                                OFFSET         <le bon>
                        ) AS alias_de_tout_ca
INNER JOIN <l'autre table> ON 
                        <la bonne jointure>
ORDER BY        <comme il faut>
OFFSET <ce qu'il faut>
LIMIT <la bonne>

Je n'ai rien d'autre qui pourrait consommer dans ce bout de code (pas de log, pas d'écriture fichier, pas d'affichage, pas de calcul), il s'agit d'une récupération de base. Je suis à sec !

Effectivement, vu sous cet angle là je comprends mieux. Dans mon esprit, la récupération ne concernait que la relecture des fichiers WAL locaux, pas le streaming via socket.

Assurément, mais cela représente un coût de stockage énorme : avec un archive_timeout a 1800, pour une base de 300Mo, dans ma configuration actuelle en trois jours de tests, et pour une base avec un volume d'activité plutot faible j'en suis deja a plus de 13 Go de WAL. Je pense baisser la taille des segments de 16Mo à par exemple 2Mo. D'ailleurs pourquoi les segments WAL dont on force le flush avec archive_timeout doivent ils nécessairement faire 16 Mo (sauf si configuré autrement bien sur) ? La prix a payer pour pouvoir se dire "je peux restaurer ma base au pire telle qu'elle etait a t-1800secondes" n'est-il pas un peu cher ?

Et oui, il me faut le log shipping !

Ah, je n'avais pas bien compris, au temps pour moi ! Pour moi, le slave commençait par relire ses WAL en local (ceux archivés par le maitre), puis redémarrait le streaming, mais que le streaming ne pouvait pas "revenir en arrière" en relisant les journaux du maître. C'est bien plus clair maintenant !

Merci beaucoup Marc pour toutes ces précisions qui couplées à une doc somme toute vraiment très bien m'ont bien éclairci l'esprit.