Forums PostgreSQL.fr

mgmpg

Membre

requête lente via fdw

Bonjour,

J'ai une requête qui ne veut pas "envoyer son where" au serveur distant (en v10.4 des 2 cotés, même machine, en debian stable).
C'est un filtre "similarity" :  where (column % search)
La colonne est indéxée, pas de souci sur la base en direct...

L'explain montre : Remote SQL: SELECT column FROM public.table
et donc malheureusement, ça filtre en local: Rows Removed by Filter: 249486 :-(

J'ai pourtant précisé "extensions 'pg_trgm'" dans le "create server", ce qui est nécessaire pour que pg pousse les filtres sur le serveur distant...

Est-ce un bug ?

mgmpg

Membre

Re : requête lente via fdw

Bon, je crois avoir trouvé une solution: ce n'est que si les fonctions sont immutables qu'elles peuvent être déportées (dixit la doc).
En faisant un simple "alter function similarity_op(text,text) immutable;" (au lieu de stable) sur la base cible et la base contenant le fdw, le sql envoyé est bien celui avec le filtre !
Et je divise par 10 le temps d'éxécution, ce qui m'arrange bien car pour un affichage de suggestions dans un champ de saisie, devoir attendre 2/3 secondes, c'était pas glop !

dverite

Membre

Re : requête lente via fdw

Elle n'est pas immutable sans doute parce que le résultat dépend du paramètre pg_trgm.similarity_threshold.

---

@DanielVerite
http://blog-postgresql.verite.pro/

mgmpg

Membre

Re : requête lente via fdw

Ah, oui, du coup, je viens de me rendre compte que je ne peux pas "envoyer" un autre threshold à la base distante :-(
(à moins que le fdw se connecte par un utilisateur dédié sur lequel on aurait fait un "alter role set th=0.1")

Qu'est ce que ça implique de passer cette fonction en immutable ? (je n'ai pas besoin d'une vue "stable" des données, c'est pour faire des recherches de titres de films...)

Dernière modification par mgmpg (18/05/2018 15:04:42)

mgmpg

Membre

Re : requête lente via fdw

J'ai trouvé un "hack" pour faire passer le similarity_threshold à la base distante: dans celle-ci, je crée plusieurs vues qui font simplement un "select set_limit()" et j'appelle la bonne vue distante avant ma vraie requete distante avec l'opérateur "%" => ça fonctionne mais il ne faudrait pas que set_limit disparaisse (marquée comme deprecated dans la doc !)

Voici une fonction qui crée autant de vues que de valeurs de similarity souhaitées:
create or replace function fc_create_set_fdw_pgtrgm_similarity_views(
        param_view_name_prefix  text,   -- can be schema prefixed, _nnn will be added after this name, ie _065 for 0.65 value
        param_from_value        float,  -- 0 to 1
        param_to_value          float,
        param_step              float
) returns setof text as $$
declare
        curr_value      numeric(3,2);
        view_name       text;
        sql_cmd         text;
begin
        curr_value=param_from_value;
        while (curr_value<=param_to_value) loop
                view_name=param_view_name_prefix||'_'||to_char(curr_value*100,'FM000');
                --
                sql_cmd='drop view if exists '||view_name||' cascade';
                execute sql_cmd;
                --
                sql_cmd='create or replace view '||view_name||' as select set_limit('||to_char(curr_value,'FM0.00')||')'; -- TODO: set_limit() is currently deprecated
                execute sql_cmd;
                return next sql_cmd;
                --
                perform fc_comment_on('view',view_name,
                        'View that just set the pg_trgm.similarity_threshold value (only way to set it for a remote fdw query with the % operator!)',current_setting('sessionvar.version',true));
                --
                curr_value=curr_value+param_step;
        end loop;
        --
        return;
end; $$
language plpgsql;

Idéalement, if faudrait pouvoir envoyer un "SET" à une base distante, y'a du patch en cours à ce sujet ?

gleu

Administrateur

Re : requête lente via fdw

Pour que l'envoi d'un SET ait du sens, il faudrait s'assurer que toutes les requêtes de la session utilisent la même connexion. Même si postgres_fdw essaie de conserver sa connexion sur une même session, il n'y a aucune garantie que ce soit le cas. En dehors de ce petit problème technique, il n'y a aucun patch en cours à ce sujet à ma connaissance.

---

Guillaume.