Re: fun fact about temp tables

From: Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: fun fact about temp tables
Date: 2016-08-05 15:16:04
Message-ID: 5a4e7bde-28ad-0315-7d74-13d879b0fb56@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On 05.08.2016 17:51, Tom Lane wrote:
> Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru> writes:
>> I`ve noticed interesting aspect in temp tables working. It appears
>> postgres is trying to reserve space on disk for temp tables even before
>> temp_buffers overflow.
> Sure. Just like it reserves space for ordinary tables right away,
> long before there's any need to push the data out of shared_buffers.
> Otherwise, you might find yourself having to throw an "out of disk
> space" error after having already committed the relevant INSERTs.
>
> regards, tom lane
>
>
How about out of space when we filling WAL files? Just rollback and
nothing else. We can fall in this with space reservation for WAL files.

In this situation with temp table we reserved space long before we ever
need it if we have size of temp table < temp_buffer.
Why not just rollback transaction in "Out of space" situation? With
this preliminary reservation we use HDD resource but in fact we dont
need it.
In situation with high rate creation of temp table, we saturate HDD
resource with "just in case" reservation.

Have we any other explanation except "out of space" problem? May be
there is some fundamental things tied with that?

Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-08-05 15:50:47 Re: fun fact about temp tables
Previous Message Grigory Smolkin 2016-08-05 15:02:08 Re: fun fact about temp tables