Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bZDxe-0006sZ-Ax for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Aug 2016 09:13:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bZDxd-0004rH-KU for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Aug 2016 09:13:33 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bZDxc-0004qM-6m for pgsql-hackers@postgresql.org; Mon, 15 Aug 2016 09:13:32 +0000 Received: from newmail.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bZDxZ-0006da-2S for pgsql-hackers@postgresql.org; Mon, 15 Aug 2016 09:13:31 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 64F8F21C2D3F for ; Mon, 15 Aug 2016 12:13:28 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Received: from mail.postgrespro.ru ([127.0.0.1]) by localhost (mail.postgrespro.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OccJkFiGGkmL for ; Mon, 15 Aug 2016 12:13:28 +0300 (MSK) Received: from e733 (unknown [192.168.27.1]) by mail.postgrespro.ru (Postfix) with ESMTPSA id 3BEC121C2D38 for ; Mon, 15 Aug 2016 12:13:28 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1471252408; bh=iBU+OWh/A1YMGTyGqoKNWUO1NMdDMMJaKYngySCEXWI=; h=Date:From:To:Subject:In-Reply-To:References; b=I7wIrGNwXVG+r89lfUVWSvNMxQ2iWdJvVKQrcCmvtRObiJ/hCP45J42mP0u2rCd68 3lBOOx1dUNZ2faP0btZN2+W5SyykiqL0FL1mQeevOIDbmVM2/zOFzv+hNtbiGtVy39 YNzQxUXmER0eXY9Mp2Wtss64li3ADqoPN5LbOnM8= Date: Mon, 15 Aug 2016 12:12:16 +0300 From: Aleksander Alekseev To: PostgreSQL Hackers Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) Message-ID: <20160815121216.46bd758d@e733> In-Reply-To: <20160815010852.5ijua2wm2edzimd4@alap3.anarazel.de> References: <20160801124531.66cde374@fujitsu> <26c3bc60-6613-e7ab-517a-53136f01fb6c@2ndquadrant.com> <13191.1470072250@sss.pgh.pa.us> <20160804151451.6fb87507@fujitsu> <14212.1470595566@sss.pgh.pa.us> <20160815005755.gswdyjfob7dzw4yp@alap3.anarazel.de> <20319.1471223097@sss.pgh.pa.us> <20160815010852.5ijua2wm2edzimd4@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org > > >>> I think the whole idea of a fast temporary table is that there > > >>> are no catalog entries. If there are no catalog entries, then > > >>> dependencies are not visible. If there ARE catalog entries, to > > >>> what do they refer? Without a pg_class entry for the table, > > >>> there's no table OID upon which to depend. > > > > >> TBH, I think that the chances of such a design getting committed > > >> are not distinguishable from zero. Tables have to have OIDs; > > >> there is just too much code that assumes that. And I seriously > > >> doubt that it will work (for any large value of "work") without > > >> catalog entries. > > > > > That seems a bit too defeatist. > > > > Huh? I didn't say we shouldn't work on the problem --- I just > > think that this particular approach isn't good. Which you seemed > > to agree with. > > I took your statement to mean that they need a pg_class entry - even > if there were a partial solution to the pg_depend problem allowing to > avoid pg_attribute entries, tha't still not really be a solution. If > that's not what you mean, sorry - and nice that we agree ;) > > Just to keep things sane I would like to remind that in this concrete patch there _are_ catalog entries: ``` [...] This file contents imlementation of special type of temporary tables --- fast temporary tables (FTT). From user perspective they work exactly as regular temporary tables. However there are no records about FTTs in pg_catalog. These records are stored in backend's memory instead and mixed with regular records during scans of catalog tables. We refer to corresponding tuples of catalog tables as "in-memory" or "virtual" tuples and to all these tuples together --- as "in-memory" or "virtual" catalog. [...] ``` As Tom pointed out a lot of PL/pgSQL code would stop working otherwise. Also I mentioned that in this case even \d and \d+ would not work. I personally find this discussion very confusing. Maybe we should concentrate on a concrete patch instead of some abstract ideas, and topics that are still open. For instance it surprises me that apparently there is no one who objects "lets make all temporary tables fast temporary tables" idea. Since in this case code would use more memory for keeping a virtual catalog wouldn't it be considered a major change of behavior that can break someones production environment? -- Best regards, Aleksander Alekseev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers