Re: blending fast and temp space volumes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Rick Otten <rottenwindfish(at)gmail(dot)com>
Cc: "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: blending fast and temp space volumes
Date: 2018-02-21 19:50:03
Message-ID: CAH2-WzmKqiUvVRpWucXQjY11Le6RkE12_zUMLExD=d8ASc6tuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Feb 21, 2018 at 7:53 AM, Rick Otten <rottenwindfish(at)gmail(dot)com> wrote:
> side note: The disadvantage of local SSD is that it won't survive "hitting
> the virtual power button" on an instance, nor can it migrate automatically
> to other hardware. (We have to hit the power button to add memory/cpu to
> the system, and sometimes the power button might get hit by accident.) This
> is OK for temp space. I never have my database come up automatically on
> boot, and I have scripted the entire setup of the temp space volume and data
> structures. I can run that script before starting the database. I've done
> some tests and it seems to work great. I don't mind rolling back any
> transaction that might be in play during a power failure.

It sounds like you're treating a temp_tablespaces tablespace as
ephemeral, which IIRC can have problems that an ephemeral
stats_temp_directory does not have.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Claudio Freire 2018-02-21 20:07:12 Re: blending fast and temp space volumes
Previous Message Craig James 2018-02-21 19:22:51 Re: blending fast and temp space volumes