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
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 |