Re: Global temporary tables

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

View thread

From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

To: Craig Ringer <craig@2ndquadrant.com>

Cc: Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2019-08-13T13:50:17Z

Lists: pgsql-hackers

Attachments

global_shared_temp-2.patch (text/x-patch) patch
global_private_temp-2.patch (text/x-patch) patch


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

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: http://www.postgrespro.com
The Russian Postgres Company