Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxqTp-0007rm-13 for pgsql-performance@arkaria.postgresql.org; Wed, 14 Aug 2019 10:26:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hxqTn-0007t4-LC for pgsql-performance@arkaria.postgresql.org; Wed, 14 Aug 2019 10:26:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxqTn-0007nb-8g for pgsql-performance@lists.postgresql.org; Wed, 14 Aug 2019 10:26:07 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxqTk-0000uG-Fx for pgsql-performance@lists.postgresql.org; Wed, 14 Aug 2019 10:26:06 +0000 Received: by mail-wr1-x444.google.com with SMTP id z11so8640823wrt.4 for ; Wed, 14 Aug 2019 03:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=xjeWi90lqHl88EnsnYnPg7woZPanI5H9f4DrBqHXTyw=; b=GakQYYegQfAannLm/PhFmEzc7NYISV3HwTYXpH3cS/OX3Mcnn79K4G6ZBScqUH8x0b XZ94wmXQoJUnL6x2v0CcuoI1HA8D3aTZjGZQsmHNd1VLRUSapyB45ShV7z3/XDT4F40p vpASn9hKNWwzjegrHVr6S5Ry1kOvWFxT1qEMvcO0n+HQhNdaYyw/+XBQW7n5PX3bFl2W 9ZlvYZFAj3fpxvxiEOhRugxoHf9mTELvVHjwdjocr9zDRblSLhFpI+yM+x5fy4BHFznf 03rDqGUkEyGMG5lEivpqY5LqWg7zl8VJS36527Lmz0aINpwDp8VkBBQI3EnHJBJNbfZV c/7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=xjeWi90lqHl88EnsnYnPg7woZPanI5H9f4DrBqHXTyw=; b=hNOgvBxUSrkhgQjlwdb955CFKgsgr0HtN0a+UUs3u5UfFnBNzctHhIBxNIEJSeQwAj 6Pqkp/y3/3R8jA8a5QkOm1/wVLMX/gV+hiOCp5eeK9zSFWtb2ykMxGvTl3RgErzK6o17 J5GowD2Ksql5zhWDdzFCeya0kpaH4zp/QJp3SxcsO5xrcvJzZ7yyRc/QT/LL99jrf14g dllHpaa3sd7xsOKURbtlzfdk/8QyImwKs93V/x3bbu73piOJexyTkixdAGqm+hyRsTvg G8gDu9Xah1ZWbYKYVeAzANrv4LXg7g2HcxuCULq13b5Lc6qnRrQNaxCZLBbhgq//bfVo YsBQ== X-Gm-Message-State: APjAAAXBcUywxjYyuhwUs3rkbOGStolXvJpHee16v6+WvIvSJnPbpnk4 zCI53mGzLwPE7c52jVIQgjYCS4oHNDM= X-Google-Smtp-Source: APXvYqyF91Q6jBVN2mxgwRzkp5a39fb8VYQlvovI5AynhctVQKwahQR+3cxjIhkIfWjSMbyzPZNY4Q== X-Received: by 2002:adf:f744:: with SMTP id z4mr31132394wrp.211.1565778360151; Wed, 14 Aug 2019 03:26:00 -0700 (PDT) Received: from localhost.localdomain (217-149-169-215.nat.highway.telekom.at. [217.149.169.215]) by smtp.gmail.com with ESMTPSA id g12sm153360065wrv.9.2019.08.14.03.25.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2019 03:25:59 -0700 (PDT) Message-ID: <60f01304bbdefa9d091145b77a117df2d7b5a5ca.camel@cybertec.at> Subject: Re: Re: performance bottlenecks on lock transactionid From: Laurenz Albe To: =?UTF-8?Q?=E7=8E=8B=E8=8B=A5=E6=A5=A0?= , pgsql-performance Date: Wed, 14 Aug 2019 12:25:58 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 王若楠 wrote: > I want to find a way to reduce the lock waiting and improve the > performance. You either have to make the transactions shorter, or you let the different clients modify different rows, so that they don't lock each other. That concurrent writers on the same data lock each other is unavoidable, and all database management systems I know do it the same way. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com