search

yugabyte / yugabyte-db

YugabyteDB - the cloud native distributed SQL database for mission-critical applications.
https://www.yugabyte.com
Other
8.99k stars 1.07k forks source link

Add support to specify "LOCATION" for Postgres Tablespace APIs #6569

Open deeps1991 opened 3 years ago

deeps1991 commented 3 years ago

Currently there are plans to support PostgreSQL Tablespaces APIs. However they will be used to specify replica placement for tables or database objects using the options through the WITH clause. The "LOCATION" parameter though accepted, is ignored with a WARNING.

jaki commented 3 years ago

Unless new points were brought up, I think it's better to extend the grammar with different rules rather than use LOCATION for replica placement. This can be through spcoptions.

deeps1991 commented 3 years ago

@jaki What you said is the current plan. I created this ticket just as a placeholder... because today if LOCATION is provided, we will issue a warning but allow the creation of table space and ignore the LOCATION option (to remain compatible with PostgreSQL create table space API)

Since with warnings we provide a GitHub issue number I’ve created this so that any user who ever needs LOCATION for any reason can add a comment here.

But replica placement will continue to be specified using spcoptions

Alibirb commented 6 months ago

Is there a way to control where a yugabyte instance stores a table/tablespace on disk?

I understand it wouldn't be done the same way as in postgres since it's a distributed system, but is there a way to configure it at all (e.g. in the configuration for an individual tablet server)?

jaki commented 6 months ago

LOCATION is currently not supported, and I don't think there are any plans to prioritize it. I don't think it would take too long to come up with a spec and code if needed, but demand seems to be low. Is there a particular workflow that makes this important for you @Alibirb? I believe you can work around it by mounting different partitions in the tablespace directories under pg_data itself (or pg_data entirely if that's what you want).

Alibirb commented 6 months ago

Our current code makes use of tablespaces with different locations in order to ensure one set of large tables (e.g. the ones storing logs) doesn't fill up the partition used by more critical tables.

I believe you can work around it by mounting different partitions in the tablespace directories under pg_data itself (or pg_data entirely if that's what you want).

So each tablespace is stored in its own directory? That should allow us to get this working the way we want it. Thanks for the info.