On Wed, Feb 21, 2018 at 4:50 PM, Peter Geoghegan <pg@xxxxxxx> wrote: > On Wed, Feb 21, 2018 at 7:53 AM, Rick Otten <rottenwindfish@xxxxxxxxx> 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. For instance? I've been doing that for years without issue. If you're careful to restore the skeleton directory structure at server boot up, I haven't had any issues. On Wed, Feb 21, 2018 at 4:22 PM, Craig James <cjames@xxxxxxxxxxxxxx> wrote: > > On Wed, Feb 21, 2018 at 7:53 AM, Rick Otten <rottenwindfish@xxxxxxxxx> >> I was wondering if there anyone had ideas for how to make that possible. >> I don't think I want to add the SAN disk to the same LVM volume group as the >> local disk, but maybe that would work, since I'm already building it with a >> script anyhow ... Is LVM smart enough to optimize radically different disk >> performances? > > > Couldn't you configure both devices into a single 6T device via RAID0 using > md? That would probably perform as slow as the slowest disk.
