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 1ir63I-0007qy-Rz for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2020 20:11: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 1ir63H-0002An-Gz for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2020 20:11: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 1ir63H-00028d-5i for pgsql-hackers@lists.postgresql.org; Mon, 13 Jan 2020 20:11:07 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ir63A-0006hq-Vl for pgsql-hackers@postgresql.org; Mon, 13 Jan 2020 20:11:06 +0000 Received: by mail-wr1-x444.google.com with SMTP id d16so9947899wre.10 for ; Mon, 13 Jan 2020 12:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4Um+bncFbEbmnlrRjYfgYg1DoQgXRbguYEiK+SaPfxA=; b=aKJdoQ3LJE6p9eiPhC6NjEKBXDW63m+Jbmn6+TnvPItEzGFI3pK1RpYmSgDpfyepQY 0DjYqmCYcYsaWNLlmBXQly/IqyBDxEg7BO+Lz+u6lRG/caYSOSCc2PMPXLXUe8C9Nn4j k/t/3wHkW12ZQQtfCQsMvgKQH+DrxvLbUApTWeilHtHevxAdCAdmbdMwZU9vc7v+Hym3 8uiwzmJUiEZM7IPmh8mJZsNPpTMEaa2vLsTeFsGBhAVtbWTlVqUy66I7FXj2tKvCTdBz 0bz7wrsFk4eGv9+FerWrEOjyK/e7BFP/CDm0UgVfCch/kc069iMioV963/Raoly4Vzi9 +LRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4Um+bncFbEbmnlrRjYfgYg1DoQgXRbguYEiK+SaPfxA=; b=IloAiD/6j4Ef/jzWLW6AI1WZI1lzAMAG8vAprLAS6c0Y+Bbxe3MdZqO7Wj83X0d5Te YBbg2RPrzo7YDdXwfcawsEfR8hm1QOAlrVJxzybWEx/N7euJEexYLeUdJpV6EZEOFBlC 5+MFjP86WONOasatOTmv8OR0vW9kWR/eGL71FXU8IjKJGQi8G3EcCOgdknrXSqv6WlVH Rs3qmfadBvr4hwVIe17i+KWFD/oJ2R0LYgGfVHu+MRKxSEFBjgtZ1Ck/m1JzcvwlscV0 3zWgyoHEm/enz6k/b0oOEboMK7sw3ZCAm3kr6tkm8JANijY/VHxbbs6zDH/1gcpsDDe1 FU8w== X-Gm-Message-State: APjAAAU4vrO+AbF/kKUnFF2GNj3tTCUp+GUicTXshEKSDdHO8AQRv3C1 HJaVrVBp82VBB7iv4twhMWw= X-Google-Smtp-Source: APXvYqxUCUWDzg6bcfxgYU71bWh2oUQHksM9C0/1bE5kWkzb44ispqZ8EwcB0MmkQJUDX1w/M3RRSw== X-Received: by 2002:adf:dd4d:: with SMTP id u13mr20932552wrm.394.1578946259103; Mon, 13 Jan 2020 12:10:59 -0800 (PST) Received: from nol ([2a01:e0a:c:bcf0:dbc8:f7e9:89ae:5cd7]) by smtp.gmail.com with ESMTPSA id n16sm16555607wro.88.2020.01.13.12.10.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2020 12:10:58 -0800 (PST) Date: Mon, 13 Jan 2020 21:12:38 +0100 From: Julien Rouhaud To: Tomas Vondra Cc: Konstantin Knizhnik , =?utf-8?B?5pu+5paH5peMKOS5ieS7jik=?= , Pavel Stehule , Robert Haas , PostgreSQL Hackers , =?utf-8?B?6JSh5p2+6ZyyKOWtkOWYiSk=?= , "Cai, Le" , =?utf-8?B?6JCn5bCR6IGqKOmTgeW6tSk=?= Subject: Re: [Proposal] Global temporary tables Message-ID: <20200113201216.GA17684@nol> References: <5767433E-1A77-4682-B3FD-4869911021C8@alibaba-inc.com> <6b7570aa-14ea-2f28-c3b5-74dd785bbafe@postgrespro.ru> <20200105200603.wrb4beacwb57hhpk@development> <33969545-BEF7-4518-A741-302CBF7FF269@alibaba-inc.com> <0498c45c-53cb-d9b0-c1e2-7d2d1a618511@postgrespro.ru> <20200109164829.mdl3z5xalmaqxs67@development> <3fef844f-0e73-8fcb-e4b6-595d6317b191@postgrespro.ru> <20200112015109.caab6qdr2ob6d5jv@development> <20200113163253.ja34iqsors3o44sv@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200113163253.ja34iqsors3o44sv@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jan 13, 2020 at 05:32:53PM +0100, Tomas Vondra wrote: > On Mon, Jan 13, 2020 at 11:08:40AM +0300, Konstantin Knizhnik wrote: > > > >"if any code tried to access the statistics directly from the table, > >rather than via the caches". > > > >Currently optimizer is accessing statistic though caches. So this > >approach works. If somebody will rewrite optimizer or provide own > >custom optimizer in extension which access statistic directly > >then it we really be a problem. But I wonder why bypassing catalog > >cache may be needed. > > > > I don't know, but it seems extensions like hypopg do it. AFAIR, hypopg only opens pg_statistic to use its tupledesc when creating statistics on hypothetical partitions, but it should otherwise never reads or need plain pg_statistic rows.