Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQWtL-0006RA-WD for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 13:55:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jQWtK-0001p1-Oy for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 13:55:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQWtK-0001os-E4 for pgsql-hackers@lists.postgresql.org; Mon, 20 Apr 2020 13:55:18 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jQWtH-0005oU-9g for pgsql-hackers@postgresql.org; Mon, 20 Apr 2020 13:55:17 +0000 Received: by mail-wm1-x32e.google.com with SMTP id u127so10414126wmg.1 for ; Mon, 20 Apr 2020 06:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :content-transfer-encoding:date:message-id; bh=HKks/rg28Jk9cJHP6vBGHxnWkQy1Pr5RuBePlG2nejQ=; b=Ab7OboAwnICLvI9wmGYX5T537NEcWK62VCTV+Otgn8Tt00mMDaM2tgYDO904/iVtlx akgoSVcy7v5a/JjCrgOJ+LLQSHkETBadIv1NRdH+JNmknr3yu4TYhb5P29Zq3d5je2+s 9Vx+/5/d3ywc5l8QMP/dShe5Evf9oyPLAMgjE4hqPRyawg6S+jJfSEjYyrMIlHzlkiX6 dFG/5fR7/+Qf10N/RHI+9XXghmYp2cRXO4/w46k0dY3TBplQ+c9Famnk/vOmVY8Jr4+t iz5H08JfA3rmD9IY96VJioCjS24NtvlqVLtCIrw1gsg2ffNZTnAs607N2XYW5/A8Tero eF8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:content-transfer-encoding:date:message-id; bh=HKks/rg28Jk9cJHP6vBGHxnWkQy1Pr5RuBePlG2nejQ=; b=ApRLwA/HYNKEYTp5K5zlf/KW4sUYHGrwSaVelBSSZQF7hcOMcqbz/xSrKIAdlRqCB1 0P8KyrV07nzv5F/LWPf9cv7BGI167psmoLLxC5kiM0KNfT+/Pq9CBM8TvrzMLKBHGWRJ 4eXzUt0o+rKZT9a1rSHEL6d6R76xTggkuXjgEmik5dVeYJKZBsGqcupehRSogMrQO4GO GI03XH/0Tsse/KGZ4V02paSdF8+KpWe5Enm6hqxSIEgNZay+9i/aqUZnfLiD8tzlGEA2 BFEf0bNXmfxd6UiGVfv3ZVIk8pEJpYg2mEDJ6GzsoKeZ8uod6Z/+vFR2j/2Tmx9Y4MhX Df+w== X-Gm-Message-State: AGi0PuaPhYTHCq4V+tjJp1a1bT1Fp4IoSdCAzGYdb8Nkw5DakLKfaU/K HxuqmwfAJPSGLZQ3bTOSOaXfzw== X-Google-Smtp-Source: APiQypJ6jBXaa7CmLebe4JJSgcREdLOoWiGjzfdYHcEv1V882Y+AuUp14BaRZFUntp5H4L7rnepyIg== X-Received: by 2002:a1c:1f09:: with SMTP id f9mr7937788wmf.31.1587390914176; Mon, 20 Apr 2020 06:55:14 -0700 (PDT) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id b82sm1601800wmh.1.2020.04.20.06.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 06:55:13 -0700 (PDT) From: Antonin Houska To: Pavel Stehule cc: PostgreSQL Hackers Subject: Re: More efficient RI checks - take 2 In-reply-to: References: <1813.1586363881@antos> Comments: In-reply-to Pavel Stehule message dated "Wed, 08 Apr 2020 19:05:45 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7; GNU Emacs 26.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2020 15:56:35 +0200 Message-ID: <8011.1587390995@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Pavel Stehule wrote: >> st 8. 4. 2020 v 18:36 odes=C3=ADlatel Antonin Houska na= psal: >=20 >> Some performance comparisons are below. (Besides the execution time, pl= ease >> note the difference in the number of trigger function executions.) In g= eneral, >> the checks are significantly faster if there are many rows to process, = and a >> bit slower when we only need to check a single row. However I'm not sur= e about >> the accuracy if only a single row is measured (if a single row check is >> performed several times, the execution time appears to fluctuate). >=20 > It is hard task to choose good strategy for immediate constraints, but for > deferred constraints you know how much rows should be checked, and then y= ou > can choose better strategy. >=20 > Is possible to use estimation for choosing method of RI checks? The exact number of rows ("batch size") is always known before the query is executed. So one problem to solve is that, when only one row is affected, we need to convince the planner that the "transient table" really contains a single row. Otherwise it can, for example, produce a hash join where the ha= sh eventually contains a single row. --=20 Antonin Houska Web: https://www.cybertec-postgresql.com