On 28.10.2019 15:13, Robert Haas wrote:
On Fri, Oct 25, 2019 at 12:22 PM Konstantin Knizhnik
<k.knizh...@postgrespro.ru> wrote:
On 25.10.2019 18:01, Robert Haas wrote:
On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
<k.knizh...@postgrespro.ru> 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
