On 13.08.2019 8:34, Craig Ringer wrote:
On Tue, 13 Aug 2019 at 00:47, Pavel Stehule <pavel.steh...@gmail.com
<mailto: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.
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.
I'll need to check, but I wonder if periodically updating those fields
in pg_class impacts logical decoding too. Logical decoding must treat
transactions with catalog changes as special cases where it creates
custom snapshots and does other expensive additional work.
(See ReorderBufferXidSetCatalogChanges in reorderbuffer.c and its
callsites). We don't actually need to know relpages and reltuples
during logical decoding. It can probably ignore relfrozenxid
and relminmxid changes too, maybe even pg_statistic changes though I'd
be less confident about that one.
At some point I need to patch in a bunch of extra tracepoints and do
some perf tracing to see how often we do potentially unnecessary
snapshot related work in logical decoding.
Temporary tables (both local and global) as well as unlogged tables are
not subject of logical replication, aren't them?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
