pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedLVM vs Tablespaces
3+ messages / 3 participants
[nested] [flat]
* LVM vs Tablespaces
@ 2015-02-25 11:28 Scott Neville <scott.neville@bluestar-software.co.uk>
0 siblings, 1 reply; 3+ messages in thread
From: Scott Neville @ 2015-02-25 11:28 UTC (permalink / raw)
To: pgsql-admin
Hi,
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?
Thanks for your time.
Scott
--
Scott Neville
Software Developer, Bluestar Software
Telephone: +44 (0)1256 882695
Web site: www.bluestar-software.co.uk
Facebook: www.facebook.com/bluestarsoftware
Email: scott.neville@bluestar-software.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DISCLAIMER: This email message and any attachments is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorised review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
The views expressed in this message may not necessarily reflect the
views of Bluestar Software Ltd.
Bluestar Software Ltd, Registered in England
Company Registration No. 03537860, VAT No. 709 2751 29
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LVM vs Tablespaces
@ 2015-02-25 11:52 Albe Laurenz <laurenz.albe@wien.gv.at>
parent: Scott Neville <scott.neville@bluestar-software.co.uk>
0 siblings, 1 reply; 3+ messages in thread
From: Albe Laurenz @ 2015-02-25 11:52 UTC (permalink / raw)
To: Scott Neville *EXTERN* <scott.neville@bluestar-software.co.uk>; pgsql-admin
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
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: LVM vs Tablespaces
@ 2015-02-25 16:48 Fernando Hevia <fhevia@gmail.com>
parent: Albe Laurenz <laurenz.albe@wien.gv.at>
0 siblings, 0 replies; 3+ messages in thread
From: Fernando Hevia @ 2015-02-25 16:48 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Scott Neville *EXTERN* <scott.neville@bluestar-software.co.uk>; pgsql-admin
On Wed, Feb 25, 2015 at 8:52 AM, Albe Laurenz <laurenz.albe@wien.gv.at>
wrote:
> 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?
>
> ...
>
> 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.
>
>
I second Albe's answer. Ease of maintenance is paramount for me so using
LVM is the better choice, more so given that performance is being taken
care on the SAN by the storage team. Of course that might not be everyone's
case.
Cheers.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2015-02-25 16:48 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-02-25 11:28 LVM vs Tablespaces Scott Neville <scott.neville@bluestar-software.co.uk>
2015-02-25 11:52 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2015-02-25 16:48 ` Fernando Hevia <fhevia@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox