Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qTjOw-00AUNV-LZ for pgsql-sql@arkaria.postgresql.org; Wed, 09 Aug 2023 13:39:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qTjOu-005Ppn-V3 for pgsql-sql@arkaria.postgresql.org; Wed, 09 Aug 2023 13:39:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qTjOu-005Ppe-I9 for pgsql-sql@lists.postgresql.org; Wed, 09 Aug 2023 13:39:00 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qTjOs-001P3z-Ei for pgsql-sql@lists.postgresql.org; Wed, 09 Aug 2023 13:38:59 +0000 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3177d3bdfb3so1555611f8f.0 for ; Wed, 09 Aug 2023 06:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691588337; x=1692193137; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=etcMmNpzS46VqvpH/Am+tPCIMOhGaAvOO+f7A5pTaBA=; b=ClTlMjvwa7gB7JkNkfvOMsL/A9aeXx+ZP1QiciYXziGQKOmfqs3RrtrZ12AOcnRRyG tPZQLrnaSw7KQG+H+x5/mxGR5cml97g+zO2keKHP4j8BsgxO9TyI/DyrkKnwTdmtKLZZ FrhcgyS2RlkcDvV5x0doW7vezGysx8obf7345QkxuLzh6AVw+wzEWd2WPLdTqI4o0zV8 wu9AcwMfxtFvnGi075msfaSkGTqeZF0QskyO7jvrksZVOzTBLambk1iMU9yZ984HhE4m vbaOAgMrOWwFjeBezEYIj7IfyIoR/mWhzeKFfMSy3QaK9KdR7w80th8aF8NPpG0l/xBy o+Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691588337; x=1692193137; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=etcMmNpzS46VqvpH/Am+tPCIMOhGaAvOO+f7A5pTaBA=; b=jNXS1OcOm3K2pS33KOxmGOBD+Sk0en2bCI9R2S3uYIVK3u9R/LwuLMTWacAPnL3IBt LmlczsC8Z3Fz2A5TMOmO86BrZHwut9crRuetu1aGVIZ6wVI4rROVrGxNPjb/vWVp08iO eQEckeRKJcEcnV4UMWEhGKMzbxdO8nKSmUNVSSNgUBcRK8YRHgyB3zOdl9TYV/av1Irz wsjUAnANeiICe0Bp6cGY2lUqPG1j2drZqJPnwkT1kgmODMO4WenIWa3jSEUnpmhawplJ DUElDJTxF0oV0dT2nL26cjcrh1VBZLZbkNgvxtziC3DTPQdj3wSh5O9RdHt3+B/4UU98 veeg== X-Gm-Message-State: AOJu0Yw5V7dRYYOyjsRXLj9Pjqr+fwstVhCz4lDQ409SVEWG9i/TrUwS vdGw/6AUYDU1G4xuwRd4lfh1/G+GyO4= X-Google-Smtp-Source: AGHT+IE3iPH2kLTzxNLd5V8aU7dXd65JzQU1X2RpJ6KCYFXqvVKdaaZ86KkWZVpytaxSnXrd03Irxg== X-Received: by 2002:a5d:4643:0:b0:317:5eb8:b1c0 with SMTP id j3-20020a5d4643000000b003175eb8b1c0mr1665270wrs.5.1691588336602; Wed, 09 Aug 2023 06:38:56 -0700 (PDT) Received: from [192.168.1.56] ([88.169.128.220]) by smtp.gmail.com with ESMTPSA id r15-20020adfdc8f000000b00317909f9985sm16809632wrj.113.2023.08.09.06.38.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Aug 2023 06:38:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------fJj5tkdlFKOHj5hAYDsRuP10" Message-ID: <40e35930-6a84-bf0e-fb91-f5db56367763@gmail.com> Date: Wed, 9 Aug 2023 15:38:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: fr To: pgsql-sql@lists.postgresql.org From: Alain Benard Subject: =?UTF-8?Q?variable_interm=c3=a9diaires?= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------fJj5tkdlFKOHj5hAYDsRuP10 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Bonjour , je dispose d'une table très volumineuse dans laquelle je voudrai mettre à jour une colonne disons 'colmaj' pour une seule année (le where annonce près de 4 millions de lignes à mettre à jour). Ma difficulté est de savoir comment optimiser cette mise à jour sachant que la valeur de la colonne colmaj à enregistrer est une variable calculée à partir des autres colonnes de cette table (et d'une autre table par jointure)  et qu'il y a différents niveaux de variables intermédiaire et qu'il sera impossible de descendre en dessous de 3 ou 4 niveaux pour ces calculs. Sur le principe je pourrais utiliser des With les uns à la suite des autres et ce serait ce qu'il y a de plus lisible mais d'un point de vue perf je sais que ça devrait être mauvais. J'essaie d'utiliser du 'LATERAL' mais je n'ai pas vraiment l'impression qu'on puisse faire plus qu'un niveau (2 avec le LATERAL); idem avec du cross join .  Enfin je vais peut-être me résoudre à faire un ensemble de procédure stockées qui calculeront les variables intermédiaires pour ensuite me fournir la valeur finale me permettant  une mise à jour du type update matable     set colmaj = maprocedure(toutes les variables utiles) where annee = 2022 Inutile de me répondre qu'il faut simplifier le calcul pour avoir moins de niveau intermédiaire car ce calcul est dicté par des scientifiques et que pour réduire le nombre de niveau il faudrait effectuer plusieurs fois les mêmes calculs (ce que j'aimerai éviter) car des variables intermédiaires sont réutilisées plusieurs fois. Qu’en pensez-vous et est-ce que finalement la procédure stockée n'est pas ce qu'il y a de plus efficace? Merci par avance. Alain. --------------fJj5tkdlFKOHj5hAYDsRuP10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Bonjour ,

je dispose d'une table très volumineuse dans laquelle je voudrai mettre à jour une colonne disons 'colmaj' pour une seule année (le where annonce près de 4 millions de lignes à mettre à jour). Ma difficulté est de savoir comment optimiser cette mise à jour sachant que la valeur de la colonne colmaj à enregistrer est une variable calculée à partir des autres colonnes de cette table (et d'une autre table par jointure)  et qu'il y a différents niveaux de variables intermédiaire et qu'il sera impossible de descendre en dessous de 3 ou 4 niveaux pour ces calculs. Sur le principe je pourrais utiliser des With les uns à la suite des autres et ce serait ce qu'il y a de plus lisible mais d'un point de vue perf je sais que ça devrait être mauvais. J'essaie d'utiliser du 'LATERAL' mais je n'ai pas vraiment l'impression qu'on puisse faire plus qu'un niveau (2 avec le LATERAL); idem avec du cross join .  Enfin je vais peut-être me résoudre à faire un ensemble de procédure stockées qui calculeront les variables intermédiaires pour ensuite me fournir la valeur finale me permettant  une mise à jour du type

update matable

    set colmaj = maprocedure(toutes les variables utiles)

where annee = 2022

Inutile de me répondre qu'il faut simplifier le calcul pour avoir moins de niveau intermédiaire car ce calcul est dicté par des scientifiques et que pour réduire le nombre de niveau il faudrait effectuer plusieurs fois les mêmes calculs (ce que j'aimerai éviter) car des variables intermédiaires sont réutilisées plusieurs fois.

Qu’en pensez-vous et est-ce que finalement la procédure stockée n'est pas ce qu'il y a de plus efficace?

Merci par avance.

Alain.


--------------fJj5tkdlFKOHj5hAYDsRuP10--