Des minima sociaux par contre.
Une discussion SQL pas académie française svp
Des minima sociaux par contre.
Une discussion SQL pas académie française svp
Empreinte PGP - Je suis les règles de Crocker.
Pour ton information, au cours d'un show Microsoft à la Porte Mailot au palais des congrès il y a un peu plus de 10 ans, le directeur de la R&D de Microsoft qui est un français, avait balancé en pleine discussion devant un millier d'auditeurs que Microsoft cherchait depuis plusieurs années à avoir un langage aussi productif que PHP… Et envisageaient d'abandonner ce projet pour apporter des éléments complémentaires à PHP. C'est ainsi que l'on a vu venir, peu après, des pilotes spécifique de SQL Server pour PHP…. Et c'est ainsi que Microsoft est passé d'un monde fermé (avec Steve Ballmer) à un monde ouvert (Satya Nadela) et est devenu aujourd'hui l'un des plus gros contributeur du libre…
L'orientation de Microsoft est claire. C'est "Cloud First". Maintenant, je vous laisse deviner que est le système d'exploitation derrière SQL Azure par exemple...
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Il faut toujours viser la lune, car même en cas d'échec on arrive dans les étoiles. O.Wilde
Mes Articles/Critiques :
Merise - Guide pratique
PHPExcel
PostgreSQL : Administration et exploitation d'une base de données
PostgreSQL : Entraînez-vous à créer et programmer une base de données relationnelle
- PDO++ : Une nouvelle façon d'utiliser PDO. Billet de blog || Code source
- PhpEcho : Un moteur de rendu en une seule classe ! Nouvelle version (release 2.3.2) publiée le 18/04/2020 : Billet de blog || Code source
Et donc ça pour toi c'est une preuve de la compétence de Microsoft niveau serveurs ? On sait pas faire donc on va arrêter d'essayer ? Et donc c'est les meilleurs ? Non mais c'est une défense originale y a pas à dire.
Ben oui ils vendent leurs services ils ne vont pas utiliser l'OS d'en face... Donc c'est ton deuxième argument ? Les serveurs Microsoft sont supérieurs parce qu'ils sont utilisés par Microsoft ? Tu es trop fort, tu devrais te lancer comme négociateur dans les brigades anti-terroriste, tu as un avenir radieux.
Ca tombe à point : https://www.reddit.com/r/PostgreSQL/..._of_databases/
Empreinte PGP - Je suis les règles de Crocker.
Mais non de toute façon Postgres c'est nul, c'est pas utilisé sur les serveurs Azure, il te faut quelle preuve de plus ?
contribue à quoi?
kde?
libreoffice?
openjdk?
gcc?
linux autrement que leur driver?
eclipse?
Apache HTTP Server?
postgres?
mariadb?
comment jugé de la qualité d'un commit? combien de ligne ajouté? combien d'enlevé?
des stats de marketeux de patron pressé de github, on sait ce que ça vaut
Setup
J'ai fait un test sur une machine Ryzen 1800, 32GB DDR4 3000.
Dual-boot : Windows 10 OEM à jour, Ubuntu 19.10 à jour.
SQL Server express (2018 ?) tout frais téléchargé à l'instant.
PostgreSQL 12.2 (Ubuntu 12.2-1.pgdg19.10+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008, 64-bit
Au passage sqlserverexpress+ssms c'est environ 1.5GB de téléchargement; postgres+pgadmin4 installé depuis le dépôt pgdg c'est dans les 150MB.
Je n'ai touché absolument à rien à la configuration de SQLServer (j'ai lu superficiellement qu'il pouvait utiliser toute la mémoire par défaut); j'ai augmenté à 500MB les shared_buffers dans pg_hba.conf. C'est une partie que je ne maîtrise pas du tout.
Construire un jeu de données un peu plus intéressant
Quel cruel manque de datasets libres au passage...data.gouv.fr est plutôt risible....
J'ai pris grosso modo toute la comédie humaine de Zola et ai mis chaque mot dans une ligne de la table :
ebook-convert vient de la super liseuse Calibre.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 curl -s https://www.ebooksgratuits.com/ebooks.php\?auteur\=Zola_Emile | sed -n 's/^.*href="newsendbook.php?id=\([0-9]*\)&format=epub.*$/\1/p' | xargs -Iyo curl -sL -o yo.epub https://www.ebooksgratuits.com/newsendbook.php\?id\=yo\&format\=epub ls *epub | xargs -Iyo ebook-convert yo yo.txt cat *.txt | awk '{split($0,a,"[[:space:][:punct:]]+");for(i in a){if(a[i]!=""){printf("%d,\"%s\"\n",VNR,a[i]);VNR++}}}' > yo.csv
Le travail de préparation des données, c'est à des années lumière plus professionnel côté linux avec notamment les coreutils et les pipes unix...
Cela donne un csv d'environ trois millions de lignes.
Question clicougnette, l'import du csv prend 20 clics sur ssms, et littéralement 2 sur pgadmin4 - ce dernier outil est développé très rapidement depuis quelques mois, il commence à me bluffer, alors que je contribue à pgModeler.
Alors c'est prêt, on y va :
Côté postgres
Côté sqlserver
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35 CREATE COLLATION ignore_accents (provider = icu, locale = 'fr-u-ks-level1-kc-false', deterministic=false); CREATE TABLE t (ID SERIAL PRIMARY KEY, DATUM VARCHAR(256) COLLATE ignore_accents); tidx=# select datum, count(datum) from t where datum ilike 'a' or datum ilike 'à' group by datum; datum | count -------+------- à | 51163 À | 2309 A | 29 a | 6391 tidx=# create statistics datum_stats on id, datum from t; CREATE STATISTICS tidx=# create index i on t (datum); CREATE INDEX tidx=# select count(datum) from t where datum='a'; count ------- 59892 (1 ligne) tidx=# explain analyze select count(datum) from t where datum='a'; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=17323.10..17323.11 rows=1 width=8) (actual time=40.816..40.816 rows=1 loops=1) -> Bitmap Heap Scan on t (cost=1122.92..17179.07 rows=57612 width=5) (actual time=16.489..37.068 rows=59892 loops=1) Recheck Cond: ((datum)::text = 'a'::text) Heap Blocks: exact=15065 -> Bitmap Index Scan on i (cost=0.00..1108.52 rows=57612 width=0) (actual time=14.798..14.798 rows=59892 loops=1) Index Cond: ((datum)::text = 'a'::text) Planning Time: 0.087 ms Execution Time: 40.843 ms (8 lignes)
A noter :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 CREATE TABLE T (ID BIGINT PRIMARY KEY, DATUM NVARCHAR(256) COLLATE French_CI_AI); create index i on T(datum); set statistics time on select count(*) from t where datum='a'; set statistics time off Temps d'analyse et de compilation de SQL Server : , Temps UC = 0 ms, temps écoulé = 0 ms. SQL Server \endash Temps d'exécution : , Temps UC = 16 ms, temps écoulé = 114 ms. Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions 1 1 SELECT COUNT(*) FROM [t] WHERE [datum]=@1 1 1 0 NULL NULL NULL NULL 1 NULL NULL NULL 0,2515709 NULL NULL SELECT 0 NULL 0 0 |--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0))) 1 2 1 Compute Scalar Compute Scalar DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0)) [Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0) 1 0 0 11 0,2515709 [Expr1002] NULL PLAN_ROW 0 1 1 1 |--Stream Aggregate(DEFINE:([Expr1004]=Count(*))) 1 3 2 Stream Aggregate Aggregate NULL [Expr1004]=Count(*) 1 0 0,0359357 11 0,2515709 [Expr1004] NULL PLAN_ROW 0 1 59892 1 |--Index Seek(OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD) 1 4 3 Index Seek Index Seek OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD NULL 59892 0,149597 0,0660382 9 0,2156352 NULL NULL PLAN_ROW 0 1
- par défaut, sql server qui crée un clustered_index est effectivement beaucoup plus rapide, d'un facteur 3 à 4.
- avec index des deux côtés, je suis assez loin de fanfaronner sur la "domination de postgres par rapport à son clone privatif", je concluerai pour ma part que les deux sont plutôt équivalents sur ce cas précis - sqlserver fait un index seek, le planner de postgres opte pour un bitmap index scan, le parcours matriciel fait sens vu le rapport volume de résultat/volume de recherche.
Par ailleurs, je doute d'avoir envie de lire 90 pages comme celle ouvrant cette enfilade :
- un bon benchmark a un description rigoureuse des configurations matérielle, système et logicielle,
- un protocole de test et des résultats détaillés, synthétiques et jolis ...
- ...sur un SCM.
C'était une expérience intéressante et m'a fait entrevoir la vague envie de considérer à continuer sur un blog ici / un site dédié / une suite publique téléchargeable sur docker/guix orchestré.
Empreinte PGP - Je suis les règles de Crocker.
Tu as mal lu, SQL Server Express est limité à 1 Go.
C'est d'ailleurs LE truc qui freine son utilisation quand on veut du 100% gratuit : cette limite est facilement atteinte et pénalise grandement les performances.
Cependant, ici la table reste toute petite, donc 1 Go de mémoire est amplement suffisant.
Pour ce qui est d'importer des données dans SQL Server, il y a la commande BULK INSERT https://docs.microsoft.com/fr-fr/sql...l-server-ver15
Ça évite les 20 clics et probablement bien plus rapide (et scriptable).
Pour le reste, il serait intéressant de refaire le test avec SQL Server et PostGreSQL sous le même OS.
L'un et l'autre peuvent tourner sous Windows et sous Linux indifféremment.
SSMS n'existe pas sous Linux, mais les outils en ligne de commande sont largement suffisants pour faire ce bench.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
On ne jouit bien que de ce qu’on partage.
Très intéressant. Et je suis d'accord avec ta conclusion, la différence est trop faible pour affirmer qu'un test très légèrement différent ne donnerait pas le résultat inverse.
Pendant que tu y es, histoire de clôturer la bataille de méthodologie, est-ce que tu pourrais refaire le même test en remplaçant l'usage de la collation par la fonction unaccent, et même la fonction écrite en SQL? Dans les deux cas, avec et sans index? Juste histoire d'enfoncer le clou et de prouver qu'il faut comparer juste ce qui est comparable, et que donc le test de SQLPro était biaisé (je me doute bien que la fonction en SQL sera plus lente, mais ça m'intéresse de savoir de combien).
Évidemment rien ne m'empêche de faire le test moi-même, seulement ce serait bien que tous les tests soient faits sur la même machine.
De plus, les collations non déterministes ne sont disponibles que sur PostgreSQL 12, donc celui qui est bloqué à une version plus ancienne peut avoir besoin d'utiliser une autre méthode. Surtout si on se retrouve avec un cas non traité par les collations ou par unaccent (une langue rare par exemple, ou un ordre de tri spécifique à un métier). Donc même si l'usage des collations est l'idéal, ce n'est pas toujours possible.
Même si avoir tout en mémoire favorise le serveur qui utilise cette technique, je reste dubitatif sur la viabilité de cette méthode en utilisation réelle: il faudrait avoir un jeu de données nettement plus gros que la mémoire disponible (on pourrait refaire le test sur une vieille bécane avec moins de 1 GO de RAM). Parce que dans la vie réelle, je doute qu'on ait toujours plus de RAM que de données à traiter.
ça porte un autre nom mais ça existe aussi pour PostgreSQL
Bonjour,
J'ai quelques questions à propos de PostgreSql version 12.
Histoire de voir ce que donnent les différents benchs sur ma machine, je tente de l'installer sur une VM.
Lorsque je regarde la documentation de SQL Server, je vois que parmi les versions préconisés, il y a ubuntu 16.04 LTS. https://docs.microsoft.com/fr-fr/sql...l-server-ver15
J'ai pas bien compris pourquoi il n'y a pas la version 18.04 ou 19.01 mais après être resté bloqué avec une Debian puis avoir galeré avec la ubuntu 18.04 je préfère rester dans les clous de l'éditeur cette fois.
Je me lance donc dans l'installation de PostgreSQL.
Je suis bêtement cette doc indiquant comment installer PG sur ubuntu 16.04 : https://www.digitalocean.com/communi...n-ubuntu-16-04
Rien de bien surprenant :
Et là, c'est le drame : ça m'installe une version 9.5
Code : Sélectionner tout - Visualiser dans une fenêtre à part apt-get install postgresql postgresql-contrib
Donc la version "officielle" de PG, c'est 9.5 ou 12 ? Quel est le statut de la 12 ? Elle est LTS ? Beta ? Où sont passés les versions 10 et 11 ?
On ne jouit bien que de ce qu’on partage.
Toutes les versions de PostgreSQL sont supportées 5 ans à partir de la sortie de la version officielle (pas de la béta). Il n'y a donc pas de différence entre une LTS et une autre, ou alors toutes sont des LTS.
La dernière stable c'est la 12, mais les 9.4, 9.5, 10 et 11 sont encore maintenues, mais uniquement pour corriger des bugs ou failles de sécurité. Pour les nouvelles fonctionnalités, c'est la 13 qui n'en est même pas encore à la béta.
En effet, le fait que Ubuntu 16.04 soit en LTS signifie qu'elle met à jour les logiciels mais uniquement pour les corrections (bugs ou failles de sécurité), pas les versions majeures!
Donc si la dernière stable en avril 2016 était la 9.5, seules les mises à jour mineures (de 9.5.0 à actuellement 9.5.21) seront apportées par la distribution.
C'est d'autant plus vrai avec PostgreSQL pour une autre raison: migrer une base de la version 9.5 à la version 12 n'est pas une opération qui peut être faite automatiquement. Donc le gars qui a installé une Ubuntu en 2016 n'a peut-être pas envie de passer du temps à migrer toutes ses bases ... sauf évidemment quand PostgreSQL 9.5 passera en phase out, et vu le rythme de sortie, Ubuntu aura produit une nouvelle LTS d'ici là.
Par contre, une chose qui est très bien avec Debian (et donc avec Ubuntu qui en est dérivée) c'est qu'il est assez facile de faire cohabiter la version 9.5 proposée par la distribution et la version 12, même simultanément (avec d'autres distributions c'est toujours possible mais pas forcément aussi facile), ce qui est très bien pour des tests comparatifs ou de non régression par exemple. C'est exactement ce que j'ai fait pour le test que je détaille dans un message précédent, car je ne souhaitais pas migrer des bases en cours d'utilisation. La seule chose à faire, c'est qu'avant de faire l'installation dans Ubuntu, il faut ajouter manuellement le repository de PostgreSQL en complément de celui d'Ubuntu (petite précision, même si cette page parle de la version 11, le repository ne change pas, il pointe désormais sur la 12). Ensuite, si une ancienne version est déjà installée, il se débrouillera pour installer la 12 avec un port différent, ce qui leur permet de cohabiter facilement.
A noter : ni unaccent(), ni remove_fr_accents() ne s'intéressent à la casse, l'ensemble retourné est donc plus petit qu'avec la collation 'CI AI'.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116 tidx=# create extension unaccent; tidx=# CREATE TABLE t2 (ID SERIAL PRIMARY KEY, DATUM VARCHAR(256)); -- "/usr/bin/psql" --command " "\\copy public.t2 (id, datum) FROM '.../yo.csv' CSV QUOTE '\"' ESCAPE '''';"" tidx=# select count(datum) from t2 where unaccent(datum)='a'; count ------- 57554 (1 ligne) tidx=# explain analyze select count(datum) from t2 where unaccent(datum)='a'; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------ Finalize Aggregate (cost=50941.68..50941.69 rows=1 width=8) (actual time=309.573..309.573 rows=1 loops=1) -> Gather (cost=50941.47..50941.68 rows=2 width=8) (actual time=309.546..314.113 rows=3 loops=1) Workers Planned: 2 Workers Launched: 2 -> Partial Aggregate (cost=49941.47..49941.48 rows=1 width=8) (actual time=291.853..291.854 rows=1 loops=3) -> Parallel Seq Scan on t2 (cost=0.00..49925.42 rows=6420 width=5) (actual time=0.538..290.831 rows=19185 loops=3) Filter: (unaccent((datum)::text) = 'a'::text) Rows Removed by Filter: 1007759 Planning Time: 0.160 ms Execution Time: 314.148 ms (10 lignes) tidx=# create or replace function unaccent2(txt varchar(256)) returns varchar(256) as $$ select unaccent(txt); $$ language sql immutable; CREATE FUNCTION tidx=# explain analyze select count(datum) from t2 where unaccent2(datum)='a'; QUERY PLAN ------------------------------------------------------------------------------------------------------------------- Aggregate (cost=839559.10..839559.11 rows=1 width=8) (actual time=5161.691..5161.691 rows=1 loops=1) -> Seq Scan on t2 (cost=0.00..839520.59 rows=15407 width=5) (actual time=44.941..5158.527 rows=57554 loops=1) Filter: ((unaccent2(datum))::text = 'a'::text) Rows Removed by Filter: 3023278 Planning Time: 0.078 ms JIT: Functions: 5 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 0.807 ms, Inlining 6.440 ms, Optimization 27.372 ms, Emission 10.947 ms, Total 45.565 ms Execution Time: 5162.546 ms (10 lignes) tidx=# create index i2 on t2(unaccent2(datum)); CREATE INDEX tidx=# explain analyze select count(datum) from t2 where unaccent2(datum)='a'; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=20244.30..20244.31 rows=1 width=8) (actual time=34.059..34.059 rows=1 loops=1) -> Bitmap Heap Scan on t2 (cost=299.81..20205.79 rows=15404 width=5) (actual time=9.453..30.367 rows=57554 loops=1) Recheck Cond: ((unaccent2(datum))::text = 'a'::text) Heap Blocks: exact=15002 -> Bitmap Index Scan on i2 (cost=0.00..295.96 rows=15404 width=0) (actual time=7.380..7.380 rows=57554 loops=1) Index Cond: ((unaccent2(datum))::text = 'a'::text) Planning Time: 0.106 ms Execution Time: 34.085 ms (8 lignes) tidx=# CREATE OR REPLACE FUNCTION remove_fr_accents(string text) tidx-# RETURNS text tidx-# AS $$ tidx$# DECLARE out_str text; tidx$# BEGIN tidx$# SELECT translate(string, 'âäàÁÂÄèéêëÈÉÊËîïÎÏôöÕÖùûüÙÛÜÿ?Çç', tidx$# 'aaaAAAeeeeEEEEiiIIooOOuuuUUUyYCc') tidx$# INTO out_str; tidx$# SELECT replace(out_str, '?', 'OE') INTO out_str; tidx$# SELECT replace(out_str, 'Æ', 'AE') INTO out_str; tidx$# SELECT replace(out_str, 'æ', 'ae') INTO out_str; tidx$# SELECT replace(out_str, '?', 'oe') INTO out_str; tidx$# RETURN out_str; tidx$# END; tidx$# $$ LANGUAGE plpgsql immutable; CREATE FUNCTION tidx=# select count(datum) from t2 where remove_fr_accents(datum)='a'; count ------- 57554 (1 ligne) tidx=# explain analyze select count(datum) from t2 where remove_fr_accents(datum)='a'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------- Aggregate (cost=824092.91..824092.92 rows=1 width=8) (actual time=29187.786..29187.786 rows=1 loops=1) -> Seq Scan on t2 (cost=0.00..824054.40 rows=15404 width=5) (actual time=49.347..29183.283 rows=57554 loops=1) Filter: (remove_fr_accents((datum)::text) = 'a'::text) Rows Removed by Filter: 3023278 Planning Time: 0.057 ms JIT: Functions: 5 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 0.881 ms, Inlining 13.959 ms, Optimization 23.250 ms, Emission 10.248 ms, Total 48.337 ms Execution Time: 29188.749 ms (10 lignes) tidx=# create index i3 on t2(remove_fr_accents(datum)); CREATE INDEX tidx=# explain analyze select count(datum) from t2 where remove_fr_accents(datum)='a'; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=30226.49..30226.50 rows=1 width=8) (actual time=32.971..32.971 rows=1 loops=1) -> Bitmap Heap Scan on t2 (cost=299.81..30187.98 rows=15404 width=5) (actual time=8.381..29.192 rows=57554 loops=1) Recheck Cond: (remove_fr_accents((datum)::text) = 'a'::text) Heap Blocks: exact=15006 -> Bitmap Index Scan on i3 (cost=0.00..295.96 rows=15404 width=0) (actual time=5.620..5.620 rows=57554 loops=1) Index Cond: (remove_fr_accents((datum)::text) = 'a'::text) Planning Time: 0.074 ms Execution Time: 33.004 ms (8 lignes)
Empreinte PGP - Je suis les règles de Crocker.
Une équipe neutre qui fait vivre une suite de cas d'usage, avec données ouvertes.
Une équipe SQL Server, une autre PostgreSQL : chacune montre le meilleur actuel de sa solution par rapport aux besoins.
L'équipe neutre analyse, synthétise et publie les résultats.
Est-ce que ça ne serait pas un super moyen pour y voir plus clair?
Empreinte PGP - Je suis les règles de Crocker.
Merci Maxime, les tests sont très intéressants
La première chose qu'on constate, c'est que quand l'index est créé correctement (avec la fonction, contrairement à ce qu'avait fait SQLPro) les performances sont largement comparables à l'usage de la collation (40 ms contre 34 ms). Le plus surprenant étant encore que la fonction remove_fr_accents, après indexation, ait les mêmes performances que unaccent2 qui fait pourtant appel à du code C.
Par contre ça montre bien qu'une fonction en SQL ne peut rivaliser avec une fonction C, au moins avant indexation, en témoigne la différence entre unaccent (314 ms sans index) et unaccent2 (5162 ms, là je suis un peu surpris quand même). Et aussi bien sûr l'importance de bien choisir son index, l'usage d'indexes sur fonction s'avérant très efficace.
Et quand bien même, on se rend compte qu'avec de vraies données (quand l'index comprend un peu plus de deux valeurs uniques), le rapport de 1 pour 300 000 est purement fantaisiste, tout au plus on est à 1 pour 250 dans le pire des cas (29 secondes sans index ni collation contre 116 ms avec collation et index de l'autre...)
C'est vrai il faudrait peut-être essayer de combiner avec lower, y compris dans l'index bien évidemment...
Empreinte PGP - Je suis les règles de Crocker.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 tidx=# create index i2 on t2(unaccent2(datum)); CREATE INDEX Durée : 10757,598 ms (00:10,758) tidx=# create index i3 on t2(remove_fr_accents(datum)); CREATE INDEX Durée : 32279,395 ms (00:32,279)
Empreinte PGP - Je suis les règles de Crocker.
Sauf erreur de ma part, cela n'a rien de surprenant :
Lorsque tu crées un index utilisant une fonction, le temps d'interrogation de la colonne est le même que ce soit une colonne calculée ou non.
Donc ici, la seule différence mesurable, c'est le temps qu'ont mis les fonctions à traiter les valeurs littérales 'a'
A ce moment, on se rend compte que les quelques millisecondes sont énormes, puisque c'est la différence nécessaire pour traiter une seule chaîne d'un seul caractère.
On peut en déduire par conséquent que la fonction d'indexation sera fortement pénalisée par la fonction SQL par rapport à la fonction C.
On ne jouit bien que de ce qu’on partage.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager