Re: Global temporary tables

On Tue, 13 Aug 2019 at 16:19, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
wrote:

>
>
> On 13.08.2019 8:34, Craig Ringer wrote:
>
> On Tue, 13 Aug 2019 at 00:47, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>
>> But Postgres is not storing this information now anywhere else except
>>> statistic, isn't it?
>>>
>>
>> not only - critical numbers are reltuples, relpages from pg_class
>>
>
> That's a very good point. relallvisible too. How's the global temp table
> impl handling that right now, since you won't be changing the pg_class row?
> AFAICS relpages doesn't need to be up to date (and reltuples certainly
> doesn't) so presumably you're just leaving them as zero?
>
> As far as I understand relpages and reltuples are set only when you
> perform "analyze" of the table.
>

Also autovacuum's autoanalyze.

What happens right now if you ANALYZE or VACUUM ANALYZE a global temp
> table? Is it just disallowed?
>
>
> No, it is not disallowed now.
> It updates the statistic and also fields in pg_class which are shared by
> all backends.
> So all backends will now build plans according to this statistic.
> Certainly it may lead to not so efficient plans if there are large
> differences in number of tuples stored in this table in different backends.
> But seems to me critical mostly in case of presence of indexes for
> temporary table. And it seems to me that users are created indexes for
> temporary tables even rarely than doing analyze for them.
>

That doesn't seem too bad TBH. Hacky but it doesn't seem dangerously wrong
and as likely to be helpful as not if clearly documented.

> Temporary tables (both local and global) as well as unlogged tables are
> not subject of logical replication, aren't them?
>
>
Right. But in the same way that they're still present in the catalogs, I
think they still affect catalog snapshots maintained by logical decoding's
historic snapshot manager as temp table creation/drop will still AFAIK
cause catalog invalidations to be written on commit. I need to double check
that.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise