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 1jQXQy-0007cC-NO for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 14:30:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jQXQv-0007S4-HW for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 14:30:01 +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 1jQXQv-0007Rx-Aj for pgsql-hackers@lists.postgresql.org; Mon, 20 Apr 2020 14:30:01 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jQXQn-00063u-W4 for pgsql-hackers@postgresql.org; Mon, 20 Apr 2020 14:30:00 +0000 Received: by mail-wm1-x32b.google.com with SMTP id r26so11683043wmh.0 for ; Mon, 20 Apr 2020 07:29:53 -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-id:date:message-id; bh=J7UGPV7KYzJudTZVzCO+SZjBUhy2wIP/rhs60CoZr60=; b=yfsNFN0xC62zDtTE8iUmYDD06N3wXpfdVueja4s1mSA6mWh8ztKMeSCWV2F/BVlM26 5AdzaXqVRYReSyIG2NDsa6vFnPoQDIwJrZNCsgi8F7BeqIzINHeGUzlqQFIM4wdGpvJh QuBfR3uuPPea++kunwKcMTmPqucMUTFE5UBw9ki2y7QTydqSKvfXlCPxY3ZdIZP4d29J e6FSvCopHPnPQOrzLI1kaj5rp+QO7d5m6pU28nXxmYM7TVUUW48bFiWswoSNsUqtjI+h gD+YTC/PnCsq2CYNQ0u6d/nNYpm8Q5uM2usohzVxG4Uqsq1nNFFZYC9yuUUgV7WKjext xZxA== 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-id:date:message-id; bh=J7UGPV7KYzJudTZVzCO+SZjBUhy2wIP/rhs60CoZr60=; b=gAL7aO6GQsRSrjpwuNLSC8rz3VMxIkRU6uW+yVyJwdTqCS4Owyt/WbXuXLlHh72A3q qJGCU2+p31Ta//eVzYufsSKbKUsBMi3Q5Q0kmJaKeLFkOJsx0q+mb5eOGXfpDojpbUgs 4pm40NNz3dhvSMTF+bsPp98ooDZ7Beke+CbHxgf+C3kfXlA+F/IYFZO7VlR25hrFp1ZR pv7kLXfqCWdSUzowkBCnABPFobae3i5vzdMmeXUmRoFkZUqsahu/0FvG1iwn87tp4EoE /kvEtFOqyJM1akdTIa6TMxRJMMowOpsdEXgHs4GDe6ojQO4j0qnOz68vEtWxaE8b/diu cK0g== X-Gm-Message-State: AGi0PuY6wv951cbByRkHqpJ3JSftKMYrzGht67WzcHYi3lVXBuREF/OD NXOFOewlihAwx7UDl0vbKOgK2g== X-Google-Smtp-Source: APiQypK0Jg/hgpiw6U6+t6ueI9joTHhOVVmFNUEZvp2+ci5adIJQjmhE9/fIASpLvb8SKsrdN8CM+A== X-Received: by 2002:a7b:ca47:: with SMTP id m7mr19201426wml.55.1587392991397; Mon, 20 Apr 2020 07:29:51 -0700 (PDT) Received: from antos ([77.87.240.5]) by smtp.gmail.com with ESMTPSA id o129sm1760925wme.16.2020.04.20.07.29.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 07:29:50 -0700 (PDT) From: Antonin Houska To: Corey Huinker cc: Pavel Stehule , PostgreSQL Hackers Subject: Re: More efficient RI checks - take 2 In-reply-to: References: <1813.1586363881@antos> Comments: In-reply-to Corey Huinker message dated "Wed, 08 Apr 2020 13:55:55 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7; GNU Emacs 26.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8277.1587393073.1@antos> Date: Mon, 20 Apr 2020 16:31:13 +0200 Message-ID: <8278.1587393073@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Corey Huinker wrote: > These numbers are very promising, and much more in line with my initial > expectations. Obviously the impact on single-row DML is of major concern, > though. Yes, I agree. > In doing my initial attempt, the feedback I was getting was that the people > who truly understood the RI checks fell into the following groups: > 1. people who wanted to remove the SPI calls from the triggers > 2. people who wanted to completely refactor RI to not use triggers > 3. people who wanted to completely refactor triggers > > While #3 is clearly beyond the scope for an endeavor like this, #1 seems > like it would nearly eliminate the 1-row penalty (we'd still have the > TupleStore initi penalty, but it would just be a handy queue structure, and > maybe that cost would be offset by removing the SPI overhead), I can imagine removal of the SPI from the current implementation (and constructing the plans "manually"), but note that the queries I use in my patch are no longer that trivial. So the SPI makes sense to me because it ensures regular query planning. As for the tuplestore, I'm not sure the startup cost is a problem: if you're concerned about the 1-row case, the row should usually be stored in memory. > and once that is done, we could see about step #2. As I said during my review of your patch last year, I think the RI semantics has too much in common with that of triggers. I'd need more info to imagine such a change. -- Antonin Houska Web: https://www.cybertec-postgresql.com