Re: BUG #14290: materialized view refresh doesn't use temp_tablespace

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: rotten(at)windfish(dot)net, "pgsql-bugs\(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14290: materialized view refresh doesn't use temp_tablespace
Date: 2016-08-24 18:53:49
Message-ID: 87wpj69fki.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>>>>> "Kevin" == Kevin Grittner <kgrittn(at)gmail(dot)com> writes:

Kevin> You are confusing two completely different things: temporary
Kevin> objects (created by statements starting with CREATE TEMPORARY)
Kevin> and temporary files (created when data spills to disk during,
Kevin> for example, a sort, hash, or materialization of data internal
Kevin> to processing some statement). The former are placed based on
Kevin> temp_tablespaces; the latter are normally placed in the
Kevin> base/pgsql_tmp/ subdirectory.

This is not true.

If temp_tablespaces is set, then all sort / hash / materialization files
will use the list of tablespaces in temp_tablespaces on a rotational
basis (to spread load). The only exception is for temp files that might
have to outlive the current transaction; these are forced into the
default tablespace of the current database. See storage/file/fd.c

However, materialized view refresh (without CONCURRENTLY) needs the new
copy of the matview's data to be in the same tablespace as the old copy,
since it moves the data into place via a heap swap. This restriction
does not apply to sort/hash/materialization files created by the
matview's query.

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2016-08-24 18:58:37 Re: BUG #14290: materialized view refresh doesn't use temp_tablespace
Previous Message Tom Lane 2016-08-24 18:51:00 Re: BUG #14294: Problem in generate series between dates