public inbox for [email protected]  

help / color / mirror / Atom feed

From: Konstantin Knizhnik <[email protected]>
To: Robert Haas <[email protected]>
Cc: 曾文旌(义从) <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: 蔡松露(子嘉) <[email protected]>
Cc: Cai, Le <[email protected]>
Cc: 张广舟(明虚) <[email protected]>
Cc: 赵殿奎 <[email protected]>
Cc: 萧少聪(铁庵) <[email protected]>
Subject: Re: [Proposal] Global temporary tables
Date: Mon, 28 Oct 2019 16:48:43 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoZyWMjpOh8SSW2hrdFi1kFTsUbjQVM6G22aHRmmDOE-Lw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CA+Tgmob_Fg9PfNjjOReJtAE4B5gc8+UqHh+tztJ_C+iRN4KHSw@mail.gmail.com>
	<[email protected]>
	<CA+TgmoZyWMjpOh8SSW2hrdFi1kFTsUbjQVM6G22aHRmmDOE-Lw@mail.gmail.com>



On 28.10.2019 15:13, Robert Haas wrote:
> On Fri, Oct 25, 2019 at 12:22 PM Konstantin Knizhnik
> <[email protected]> wrote:
>> On 25.10.2019 18:01, Robert Haas wrote:
>>> On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
>>> <[email protected]> wrote:
>>>> Just to clarify.
>>>> I have now proposed several different solutions for GTT:
>>>>
>>>> Shared vs. private buffers for GTT:
>>>> 1. Private buffers. This is least invasive patch, requiring no changes in relfilenodes.
>>>> 2. Shared buffers. Requires changing relfilenode but supports parallel query execution for GTT.
>>> I vote for #1. I think parallel query for temp objects may be a
>>> desirable feature, but I don't think it should be the job of a patch
>>> implementing GTTs to make it happen. In fact, I think it would be an
>>> actively bad idea, because I suspect that if we do eventually support
>>> temp relations for parallel query, we're going to want a solution that
>>> is shared between regular temp tables and global temp tables, not
>>> separate solutions for each.
>> Sorry, may be I do not not understand you.
>> It seems to me that there is only one thing preventing usage of
>> temporary tables in parallel plans: private buffers.
>> If global temporary tables are accessed as normal tables though shared
>> buffers then them can be used in parallel queries
>> and no extra support is required for it.
>> At least I have checked that parallel queries are correctly worked for
>> my implementation of GTT with shared buffers.
>> So I do not understand about which "separate solutions" you are talking
>> about.
>>
>> I can agree that private buffers may be  good starting point for GTT
>> implementation, because it is less invasive and GTT access speed is
>> exactly the same as of normal temp tables.
>> But I do not understand your argument why it is "actively bad idea".
> Well, it sounds like you're talking about ending up in a situation
> where local temporary tables are still in private buffers, but global
> temporary table data is in shared buffers. I think that would be
> inconsistent. And it would mean that when somebody wanted to make
> local temporary tables accessible in parallel query, they'd have to
> write a patch for that.  In other words, I don't support dividing the
> patches like this:
>
> Patch #1: Support global temporary tables + allow global temporary
> tables to used by parallel query
> Patch #2: Allow local temporary tables to be used by parallel query
>
> I support dividing them like this:
>
> Patch #1: Support global temporary tables
> Patch #2: Allow (all kinds of) temporary tables to be used by parallel query
>
> The second division looks a lot cleaner to me, although as always I
> might be missing something.
>
Logically it may be good decision. But piratically support of parallel 
access to GTT requires just accessing their data through shared buffer.
But in case of local temp tables we need also need to some how share 
table's metadata between parallel workers. It seems to be much more 
complicated if ever possible.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

view thread (492+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [Proposal] Global temporary tables
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox