From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Index build temp files |
Date: | 2013-01-09 00:04:32 |
Message-ID: | 5417.1357689872@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>> Well, our docs for temp_tablespaces says:
>> This variable specifies tablespaces in which to create temporary
>> objects (temp tables and indexes on temp tables) when a
>> <command>CREATE</> command does not explicitly specify a tablespace.
>> Temporary files for purposes such as sorting large data sets
>> are also created in these tablespaces.
>>
>> Are you saying this is inaccorate?
> Yes and no? Are the temporary files created during a CREATE INDEX
> considered "Temporary files for purposes such as sorting large data
> sets"? My thinking is 'yes', but others may disagree. Also,
> considering this a bug would imply that it's back-patchable and I'm not
> convinced it's worth the risk of breaking things which depend on the
> current behavior.
I don't think it's a bug. What you seem to be proposing is that CREATE
INDEX ought to ignore temp_tablespaces and instead always put its temp
files in the tablespace where the finished index will reside. This
would not be a good idea IMO --- allowing the temp files to be spread to
other tablespaces is better both from the standpoint of space usage and
the ability to overlap I/O. (Admittedly, both of those concerns are
often theoretical, but if they are then I don't see why you'd care which
tablespace is used.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-01-09 00:16:24 | Re: Index build temp files |
Previous Message | Tom Lane | 2013-01-08 23:23:30 | Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it |