Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le
baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met
à jour les données et vu le code ça semble malheureusement se faire à coup
de DELETE/INSERT et pas d'UPDATE...
Le fill factor (taux de remplissage) est lié à l'orgnisation interne des
tables d'une base de données: les tables stockent les lignes par pages de
taille fixe dans lesquelles on agrège une ou plusieurs lignes; chaque page
est l'élement de base d'une organisation d'une des diverses variantes de
A voir pourquoi ça a été codé comme ça dans osm2pgsql... il y a peut être
une bonne raison.
Celle que je vois est liée à l'absence de commande REPLACE comme on la
trouve dans MySQL.
Du coup, il faudrait différencier les créations des mises à jour, ce qui
aurait un effet de bord important si on
Je pensais plutôt à tester la présence (via un SELECT sur l'osm_id, qui
doit être un champ indexé, je suppose...) et, selon la réponse, à faire un
INSERT ou un UPDATE.
Si un SELECT est sensiblement aussi rapide qu'un DELETE, et un INSERT aussi
rapide qu'un UPDATE, tu ne verras pas de différence
En terme d'I/O cela ne changera pas grand chose.
Même faire un UPDATE à la place d'un DELETE/INSERT n'aura pas grande
incidence tout bonnement car le premier DELETE aura déjà chargé les pages
qui seront les mêmes que celles affectées par l'INSERT qui suit pour mettre
à jour les index: elles sont
DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
vient de créer un trou, mais au passage il peut aussi utiliser n'importe
quelle autre page déjà en mémoire si cette autre page permet un meilleur
équilbrage de l'arbre que de réutiliser l'ancienne page: le but est
Le 12/08/2014 18:47, Philippe Verdy a écrit :
DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
vient de créer un trou, mais au passage il peut aussi utiliser n'importe
quelle autre page déjà en mémoire si cette autre page permet un meilleur
équilbrage de l'arbre que de
Le 12 août 2014 19:06, Christophe Merlet red...@redfoxcenter.org a écrit :
Le 12/08/2014 18:47, Philippe Verdy a écrit :
DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
vient de créer un trou, mais au passage il peut aussi utiliser n'importe
quelle autre page déjà
Le 12 août 2014 18:38, Philippe Verdy verd...@wanadoo.fr a écrit :
En terme d'I/O cela ne changera pas grand chose.
Même faire un UPDATE à la place d'un DELETE/INSERT n'aura pas grande
incidence tout bonnement car le premier DELETE aura déjà chargé les pages
qui seront les mêmes que celles
Le 12 août 2014 21:07, Christophe Merlet red...@redfoxcenter.org a écrit :
Le 12/08/2014 20:44, Christian Quest a écrit :
Ah bon, postgres n'essaye pas de faire un update sur place quand c'est
possible ?
Non. UPDATE étant une opération de type DELETE/INSERT (
Le 12/08/2014 21:38, Christian Quest a écrit :
Le 12 août 2014 21:07, Christophe Merlet red...@redfoxcenter.org
mailto:red...@redfoxcenter.org a écrit :
Le 12/08/2014 20:44, Christian Quest a écrit :
Ah bon, postgres n'essaye pas de faire un update sur place quand
c'est
Le 12 août 2014 21:17, Christian Quest cqu...@openstreetmap.fr a écrit :
Même un UPDATE pourrait avoir poru effet de réorganiser des pages pour
maintenir le fill factor, car l'UPDATE peut changer la taille d'une ligne
de table (en plus ou en moins).
Tout dépend comment le fillfactor est
Le 12 août 2014 22:09, Christophe Merlet red...@redfoxcenter.org a écrit :
Le 12/08/2014 21:38, Christian Quest a écrit :
Le 12 août 2014 21:07, Christophe Merlet red...@redfoxcenter.org
mailto:red...@redfoxcenter.org a écrit :
Le 12/08/2014 20:44, Christian Quest a écrit :
Ah
13 matches
Mail list logo
