Re: Global temporary tables

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Global temporary tables
Date: 2019-08-13 13:50:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 13.08.2019 11:27, Craig Ringer wrote:
> On Tue, 13 Aug 2019 at 16:19, Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru <mailto: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 <mailto: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.

When it happen?
I have created normal table, populated it with some data and then wait
several hours but pg_class was not updated for this table.

I attach to this mail slightly refactored versions of this patches with
fixes of issues reported in your review.

Konstantin Knizhnik
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
global_shared_temp-2.patch text/x-patch 73.8 KB
global_private_temp-2.patch text/x-patch 51.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-08-13 14:01:27 Re: progress report for ANALYZE
Previous Message Alvaro Herrera 2019-08-13 13:24:13 Re: errbacktrace