Re: Implementation of global temporary tables?

2015-07-15 15:21 GMT+02:00 Zhaomo Yang <zhy001(at)cs(dot)ucsd(dot)edu>:

> > Sounds fine in general. I'm a bit curious to know what are the locking
> implications of > vivifying the table on access.
>
> The locking implications depend on how we interpret the existing commands
> in the context of global temp tables and I think we should discuss and
> agree on the behaviors of the commands with global temp tables, but I think
> in general we can follow these rules:
>
> If the command executes on the global temp table's metadata, for example
> an ALTER TABLE command, then we lock the global copy at the same level as
> we do a regular table.
>

there is other question - what is effect of ALTER TABLE of global temp
table on instances of this table in active sessions?

>
> If the command executes on the global temp table's data (which is actually
> stored in the session copy), for example an DML command, then the global
> copy is locked at the AccessShareLock level to prevent concurrent
> modifications to the global temp table's definition from other sessions.
>
> Thanks,
> Zhaomo
>
> On Wed, Jul 15, 2015 at 4:26 AM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
>
>>
>> On 07/15/2015 07:58 AM, Simon Riggs wrote:
>>
>>
>>> For me the design summary is this
>>>
>>> * CREATE GLOBAL TEMP TABLE creates catalog entries like a normal table
>>> but with different relkind
>>> * When we see a request to INSERT, DEL, UPD, SEL from the temp table, if
>>> it does not exist we create it as a TEMP table of the same name, using the
>>> Global's pg_class entry as a template
>>>
>>> That meets the SQL Standard and doesn't contain any visibility problems
>>> or need for new internals.
>>>
>>> The purpose of this feature is to automatically create a temp table with
>>> the same definition whenever needed. The discussion of "bloat" is just
>>> wrong. We create exactly the same amount of bloat as if we had typed CREATE
>>> TEMP TABLE. Optimising temp table entries in the catalog is another,
>>> separate patch, if we care.
>>>
>>>
>>>
>> Sounds fine in general. I'm a bit curious to know what are the locking
>> implications of vivifying the table on access.
>>
>> cheers
>>
>> andrew
>>
>
>