On Tue, 13 Aug 2019 at 16:19, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote:
> > > On 13.08.2019 8:34, Craig Ringer wrote: > > On Tue, 13 Aug 2019 at 00:47, Pavel Stehule <pavel.steh...@gmail.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
