Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fapFo-0003R9-4h for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jul 2018 21:24:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fapFm-0007b3-J7 for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Jul 2018 21:23:58 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fapFm-0007aw-9M for pgsql-hackers@lists.postgresql.org; Wed, 04 Jul 2018 21:23:58 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fapFj-00011c-W0 for pgsql-hackers@postgresql.org; Wed, 04 Jul 2018 21:23:57 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w64LNpHe005208; Wed, 4 Jul 2018 17:23:52 -0400 From: Tom Lane To: Kyotaro HORIGUCHI cc: robertmhaas@gmail.com, pgsql-hackers@postgresql.org Subject: Re: shared-memory based stats collector In-reply-to: <20180703.190144.222427588.horiguchi.kyotaro@lab.ntt.co.jp> References: <20180629.173418.190173462.horiguchi.kyotaro@lab.ntt.co.jp> <20180703.190144.222427588.horiguchi.kyotaro@lab.ntt.co.jp> Comments: In-reply-to Kyotaro HORIGUCHI message dated "Tue, 03 Jul 2018 19:01:44 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67469.1530739431.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Jul 2018 17:23:51 -0400 Message-ID: <67470.1530739431@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Kyotaro HORIGUCHI writes: > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas w= rote in >> Copying the whole hash table kinds of sucks, partly because of the >> time it will take to copy it, but also because it means that memory >> usage is still O(nbackends * ntables). Without looking at the patch, >> I'm guessing that you're doing that because we need a way to show each >> transaction a consistent snapshot of the data, and I admit that I >> don't see another obvious way to tackle that problem. Still, it would >> be nice if we had a better idea. > The consistency here means "repeatable read" of an object's stats > entry, not a snapshot covering all objects. We don't need to copy > all the entries at once following this definition. The attached > version makes a cache entry only for requested objects. Uh, what? That's basically destroying the long-standing semantics of statistics snapshots. I do not think we can consider that acceptable. As an example, it would mean that scan counts for indexes would not match up with scan counts for their tables. regards, tom lane