Re: Transaction en erreur sur CLOSE ou INSERT

Ok, dans une fonction c'est moins pénalisant. C'est malgré tout plus couteux,
pour rien : on regarde quelle opération faire au lieu de la faire. J'ai pris
un raccourci en ne parlant que des latences réseau.

Les deux solutions peuvent être mises en place dans une fonction, mais celle à
trois ordres sera moins performante (enfin je n'ai pas fait de bench de ca
sous postgresql, seulement sous Oracle) : il y a le simple fait d'exécuter un
ordre de plus, qui fait une commutation entre le moteur pl et le moteur sql
(couteux) sous oracle, ca l'est peut être moins sous Postgresql.

Il n'y a aucun intérêt à faire un ordre de plus, si ce n'est se ramener à une
logique de langage de programmation classique, pour ne pas faire
d'interception d'erreurs. Ca marche bien sur un test de variable, mais sur
une interrogation de base de données, le cout est beaucoup plus élevé. Pour
les ordres simples comme ceux la, moins il y a d'ordres, plus c'est rapide...

Mais tout à fait d'accord, c'est le genre de cas ou il faut être précis dans
les explications, les erreurs de conception dans ce domaine pouvant coûter
assez cher :)

Le Monday 12 January 2009 11:45:35 Stephane Bortzmeyer, vous avez écrit :
> On Mon, Jan 12, 2009 at 11:40:16AM +0100,
> Marc Cousin <mcousin(at)sigma(dot)fr> wrote
>
> a message of 28 lines which said:
> > Si mais la dernière version (SELECT,INSERT,UPDATE) oblige à faire au
> > moins 2 ordres à chaque fois, ce qui la rendra probablement moins
> > performante (à cause du dialogue client-serveur).
>
> Ah non, ça, ce n'est pas une bonne raison. Ma solution peut être mise
> en oeuvre dans une FUNCTION et, dans ce cas, il n'y aura qu'un seul
> aller-retour client-serveur. (Et ça simplifiera la vie du
> programmeur.)
>
> Non, son vrai problème de performance est qu'elle fait toujours deux
> opérations alors que l'algorithme optimiste (essayer d'abord et
> réparer si nécessaire) peut n'en utiliser qu'une seule.