Make 100% sure that you have an index on the field "idfildo" in the table you're updating. That will almost always make a huge difference.

Thank you for your answer.

I created an index on idfildo, the project runs still slowly.

I have this alert message :

"The project may run slowly because the attributes are being saved on all output ports."

Have you switched off feature caching in the workspace?

See https://knowledge.safe.com/articles/79739/feature-caching-and-performance.html

Yes I switched off feature caching in the workspace.

Maybe I need to index the fields idfildoamaont and idfildoaval too ?

If it is not working, maybe I can use the DatabaseUpadter transformer ?

If ref_assainissement.canaexp is a regular table, then indexing idfiloaval and idfildoamont would probably not make a difference.

You can always try the DatabaseUpdater, but there is no logical reason (to me) why it should make a big difference, although I'd love to hear if that is the case!

What happens if you disable the SQLExecutor and then run the workspace? Is it still slow, or suddenly much faster? The idea is to get a feeling for how much time the update operations is taking.

It takes 21 secondes if a I disable the SQL Executor.

What about this message ? "The project may run slowly because the attributes are being saved on all output ports."

Can you show this message in a context? Screen grab, e.g.

It usually means that feature caching is ON.

Just a question: how many features are entering the SQLExecutor?

Since I cannot see any references to feature attributes in the SQL command, I would say that only one feature should enter, since otherwise you're simply executing the exact same command many times.

Sorry I don't understand your comment.

About 100 000 feature for each reader.

It's working with 2 featuremerger and attributecreator.

Bonjour, vous préférez peut-être une réponse en français? Ma question était: en regardant le code SQL dans votre SQLExecutor, je ne vois aucune référence à un attribut FME. Ma conclusion est donc que le code SQL reste inchangé d'un feature à l'autre, et dans ce cas je ne comprends pas pourquoi vous allez exécuter exactment la même commande 200'000 fois -- est-ce nécessaire? Ou est-ce que j'ai mal compris?

Herre is the information message :

If you are using the sql executor, you don't need to read the PostgreSQL spatial tables, you just need a single trigger feature to execute the query once (or an SQLCreator)

Oui en français c'est mieux mais la question reste floue :)

Pourquoi devrais-je faire référence à un attribut FME ?

Je veux mettre à jour tous les objets de ce champ avec cette requête, comme je le ferai directement en SQL dans un outil d'admistration de données (PGAdmin par exple).

Avec le workspace actuel, le code SQL est exécuté une fois pour chaque enregistrement (feature) lu des tables Postgresql. Par contre, le code SQL agit sur toute la table d'un coup. Alors je pense qu'il n'est pas nécessaire de l'exécuter plus qu'un seule fois, voir la suggestion de @ebygomm