| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Peter <pmc(at)citylink(dot)dinoex(dot)sub(dot)org>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SELECT creates millions of temp files in a single directory |
| Date: | 2022-04-23 21:13:41 |
| Message-ID: | 3989726.1650748421@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> I'll add that given the nature of the problem that changing temp_file_limit
> away from its default of unlimited may be useful.
> https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK
Maybe ... that limits the total space involved, not the number of
files it's separated into, so I'm not sure how much it can help.
It might be worth playing around to see how varying values of work_mem
affect this behavior, too. That should change the planner's initial
estimate of the number of hash batches needed, which likely plays into
this somehow.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter | 2022-04-23 21:58:42 | Re: SELECT creates millions of temp files in a single directory |
| Previous Message | Adrian Klaver | 2022-04-23 21:11:00 | Re: SELECT creates millions of temp files in a single directory |