Table-space documentation

Started by PG Bug reporting formover 2 years ago3 messagesdocs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/manage-ag-tablespaces.html
Description:

While reading the table-space documentation
https://www.postgresql.org/docs/16/manage-ag-tablespaces.html the
information I was looking for was not included. The page invites feedback,
so I though I would share. I was specifically looking for information on
maximum table-space size and whether there is a use-case in which you would
create several table-spaces to split your tables / indexes logically. I am
from an Oracle world and it is normal for me to think about creating
multiple table-spaces for groups of tables and placing a size on the
table-space so that space does not extend and fill the o/s disk-space. It
would be nice for the documentation to include information about this topic.
Even if it is says that these factors I should not worry about as postgres
handles them.

#2David G. Johnston
david.g.johnston@gmail.com
In reply to: PG Bug reporting form (#1)
Re: Table-space documentation

On Sunday, November 26, 2023, PG Doc comments form <noreply@postgresql.org>
wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/manage-ag-tablespaces.html
Description:

While reading the table-space documentation
https://www.postgresql.org/docs/16/manage-ag-tablespaces.html the
information I was looking for was not included. The page invites feedback,
so I though I would share. I was specifically looking for information on
maximum table-space size and whether there is a use-case in which you would
create several table-spaces to split your tables / indexes logically. I am
from an Oracle world and it is normal for me to think about creating
multiple table-spaces for groups of tables and placing a size on the
table-space so that space does not extend and fill the o/s disk-space. It
would be nice for the documentation to include information about this
topic.
Even if it is says that these factors I should not worry about as postgres
handles them.

We tend to avoid documenting things that don’t exist. So the lack of a
documented limit or any syntax to define one means no limit exists.

As for usage patterns, there is a note I thought (maybe wiki FAQ?) that
since the only thing you get with a tablespace is another root level
storage place having more than one per disk really serves no purpose.

David J.

#3Laurenz Albe
laurenz.albe@cybertec.at
In reply to: PG Bug reporting form (#1)
Re: Table-space documentation

On Sun, 2023-11-26 at 21:41 +0000, PG Doc comments form wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/manage-ag-tablespaces.html
Description:

While reading the table-space documentation
https://www.postgresql.org/docs/16/manage-ag-tablespaces.html the
information I was looking for was not included. The page invites feedback,
so I though I would share. I was specifically looking for information on
maximum table-space size and whether there is a use-case in which you would
create several table-spaces to split your tables / indexes logically. I am
from an Oracle world and it is normal for me to think about creating
multiple table-spaces for groups of tables and placing a size on the
table-space so that space does not extend and fill the o/s disk-space. It
would be nice for the documentation to include information about this topic.
Even if it is says that these factors I should not worry about as postgres
handles them.

There is no maximum tablespace size, other than the size of the filesystem
the tablespace is on.

In 99% of all cases, don't create a tablespace in PostgreSQL. Just use
the default tablespace.

In a virtualized environment, don't ever create a tablespace.

Tablespaces were more important back what people had physical boxes
with physical disks of limited size.

There are still some use cases, but they are extremely rare.

Yours,
Laurenz Albe