| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Frits Jalvingh <jal(at)etc(dot)to> |
| Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fwd: temp_file_limit? |
| Date: | 2022-12-19 20:07:48 |
| Message-ID: | CA+hUKG+LqromTMC45XrtANtd3DJaywvZ3i7inkfuhY5EmduBSg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Dec 20, 2022 at 8:59 AM Frits Jalvingh <jal(at)etc(dot)to> wrote:
> @ranier
> These files ONLY exist during the query. They get deleted as soon as the query terminates, by Postgres itself. Once the query terminates pgsql_tmp is completely empty. Considering what Thomas said (and the actual occurrence of the files he mentioned) this does seem to be the more likely cause to me.
I'm working on some bug fixes near this area at the moment, so I'll
also see if I can figure out how to implement the missing eager
cleanup of earlier generations. It's still a pretty bad scenario once
you reach it (repartitioning repeatedly, that is) and the solution to
that it probably much harder, but it's obviously not great to waste
temporary disk space like that. BTW you can disable just parallel
hash with enable_parallel_hash=false.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Frits Jalvingh | 2022-12-19 20:10:27 | Re: Fwd: temp_file_limit? |
| Previous Message | Frits Jalvingh | 2022-12-19 19:59:31 | Re: Fwd: temp_file_limit? |