Scott Neville wrote:
> I am curious what people think on this subject. In the case that you have a database running on
> hardware which has two separate data volumes (lets call them data1 and data2), what is the "best" way
> for PostgreSQL to use those two volumes? So sitting here I can think of two very simple ways of
> allowing PostgreSQL to use those two volumes:
>
> 1) Tablespaces with simple partitions - This is simply create them as /data1 and /data2 then run
> "create tablespace" to create an additional tablespace on the second data partition then move objects
> into it.
> 2) LVM - Use LVM to create one single partition (which encompasses both volumes, for the purposes of
> this I am assuming these volumes are already redundant behind hardware raid), then we have the default
> tablespace which sits on the larger LVM volume.
>
> So what do people think is the "best" way and why? By "best", I dont have any preconditions in mind,
> some people may consider blistering performance to be the number one concern and others may consider
> ease of maintenance to be the number one, either way both are valid interpretations of "best" and
> there might be different answers, hence I am wondering what people think is best and what makes it
> best?
With Version 1 you might end up with better I/O-performance because you'll use two
devices with two I/O queues, but I'm not sure of that.
When it comes to ease of maintenance, version 2 (striping) is much better, because you
don't have to manage tablespaces, which can be a pain for backup/restore.
You also don't have to think about data placement.
We have a setup like version 2 and are pretty happy with it.
Yours,
Laurenz Albe