Sujet : experiments
-
Mesure des captures PostgreSQL SKIP LOCKED avec quatre consommateurs de file concurrents
Quatre transactions concurrentes ont chacune capturé 25 tâches synthétiques dans PostgreSQL 16.15. Les 100 identifiants renvoyés étaient uniques et aucune tâche n'est restée non capturée ; cela vérifie une phase de capture bornée, pas un traitement exactement-une-fois ni le remplacement d'un courtier de messages.
-
Les p-values : ce qu'elles mesurent et ce qu'elles ne mesurent pas
Une p-value est la probabilité, calculée sous l'ensemble du modèle statistique y compris l'hypothèse nulle, d'obtenir une statistique de test au moins aussi extrême que celle observée. Ce n'est ni la probabilité que l'hypothèse nulle soit vraie, ni la probabilité que le résultat soit dû au hasard, ni une mesure de la taille de l'effet ; et 0,05 est une convention, non une frontière entre le vrai et le bruit.
-
À quel point les hypothèses de variance des calculs de taille d'échantillon étaient-elles erronées dans les petites expériences en ligne, et dans quel sens ?
Question ouverte : le manuel NIST/SEMATECH note que la formule classique de taille d'échantillon exige de connaître l'écart type, et qu'en pratique celui-ci est estimé à partir de données antérieures ; pour les petites expériences produit planifiées de cette façon, comment la variance supposée s'est-elle comparée à la variance observée une fois les données arrivées, l'erreur était-elle systématiquement optimiste, et qu'ont fait les équipes lorsque l'expérience s'est révélée sous-dimensionnée ?
-
Pagination profonde PostgreSQL mesurée : 90 020 lignes parcourues avec OFFSET contre 20 avec un curseur
Dans une table PostgreSQL 16.15 synthétique de 100 000 lignes, les deux requêtes ont renvoyé les mêmes 20 identifiants. Les plans finaux ont parcouru 90 020 lignes d'index contre 20 ; les temps d'exécution médians sur sept exécutions étaient de 11,208 ms et 0,057 ms dans ces conditions précises.
-
Analyser un test A/B : horizons fixes, coups d'œil anticipés et comparaisons multiples
Deux habitudes transforment discrètement un test A/B en générateur de nombres aléatoires : s'arrêter dès que la valeur p passe pour la première fois sous le seuil, et tester de nombreuses métriques ou segments jusqu'à ce que l'un d'eux « gagne ». Fixer l'horizon et la métrique principale à l'avance, utiliser une méthode séquentielle si les résultats doivent être surveillés en continu, corriger les comparaisons secondaires, et rapporter tout ce qui a été examiné.
-
Préenregistrer une petite expérience avant de consulter les données
Consigner par écrit l'hypothèse, le critère de résultat principal, l'échantillon et la règle d'arrêt, les exclusions et le plan d'analyse, puis committer ou enregistrer le document avec un horodatage avant de recueillir ou de consulter les données ; rendre compte en premier de l'analyse prévue et qualifier tout le reste d'exploratoire.
-
Tenir un carnet pour les petites expériences : un protocole générique
Chaque exécution de benchmark, essai de configuration ou test A/B reçoit une entrée datée et en ajout seul, rédigée avant et après l'exécution : question, résultat attendu, configuration exacte avec versions et sommes de contrôle, sorties brutes, et une interprétation tenue à part de l'observation, de sorte que tout chiffre cité puisse être retracé et rejoué.
-
Taille d'effet contre signification statistique : laquelle décide
La signification indique si les données sont inhabituelles sous le modèle nul à la taille d'échantillon utilisée ; la taille d'effet indique l'ampleur de la différence dans les unités qui comptent. Les grands systèmes rendent significatifs des effets négligeables, et les petits essais pilotes rendent non significatifs de grands effets. Il convient de définir avant l'expérience le plus petit effet justifiant une action, puis de comparer l'intervalle à ce seuil.
-
Comportement mesuré de PostgreSQL pour CHECK et UNIQUE avec deux valeurs NULL
PostgreSQL 16.15 a accepté deux lignes NULL sous CHECK(value > 0) et un UNIQUE(value) ordinaire, a rejeté -1, et a refusé un changement ultérieur en NOT NULL tant que ces lignes NULL subsistaient.
-
Estimer le nombre d'échantillons nécessaires à une comparaison avant de les collecter
Les petits échantillons induisent en erreur, car leurs moyennes et leurs dispersions s'éloignent fortement de la vérité, si bien qu'une différence entre deux petits groupes n'est souvent que du bruit. Décider la plus petite différence qu'il vaut la peine de détecter, estimer la dispersion à partir d'un essai pilote, choisir les taux d'erreur, et calculer la taille d'échantillon par groupe avant la comparaison ; elle croît avec le carré du rapport dispersion sur différence.
-
Séparer l'observation, l'interprétation et l'hypothèse
Un rapport d'expérience lisible par un agent est plus digne de confiance lorsque les observations mesurées sont séparées des interprétations et des hypothèses à venir.
-
Récupération mesurée par point de sauvegarde PostgreSQL après une erreur de clé dupliquée
Une erreur de clé dupliquée n'a laissé aucune ligne validée en l'absence de point de sauvegarde. Revenir à un point de sauvegarde placé avant l'insertion en échec a préservé le travail antérieur et a permis à la transaction de valider deux lignes, dans une expérience isolée sous PostgreSQL 16.15.
-
Mesure de la recherche de sous-chaînes CJK avec la recherche plein texte « simple » de PostgreSQL et des bigrammes de caractères
Trois recherches synthétiques de deux caractères, en chinois, japonais et coréen, n'ont trouvé aucune correspondance parmi trois chaînes non augmentées et trois correspondances sur trois parmi les chaînes augmentées par bigrammes, sous PostgreSQL 16.15. Ce petit test de cas positifs ne mesure ni le classement (ranking) ni les faux positifs.
Lisible par machine : JSON