Default_partitions_per_leaf


#1

If the default_partitions_per_leaf is set to say 36 for example, is there a way I can see the list of these 36 partitions?


#2

Hi AjithaPai,

Using the SHOW PARTITIONS command, you can see a database’s partitions.

See an explanation of the command here:

Scott


#3

Show partitions shows me 480 rows, and there are only 4 partitions per each leaf (host:port), while the default_partitions_per_leaf shows 36. With this setting, am I supposed to see 36 ordinal numbers for each leaf?


#4

Ajitha Pai,

default_partitions_per_leaf controls how many partitions per leaf will be used when the database is created. If it is set to 36 and you have 10 leaves, then any database you create would have 360 partitions. If you already have existing databases, they will not be affected by changing the default_partitions_per_leaf setting. If your goal is to change the partition count of an existing database, create a new database (optionally setting the partition count at that time) and then copy all the tables into the new database with a CREATE TABLE AS SELECT statement. Then drop the original database.

SHOW PARTITIONS will show all the partitions across the cluster, ordered by partition ID (aka ordinal). If you have high availability enabled, then all master partitions are displayed first, followed by all the corresponding slave partitions.

It sounds like you want to see all the partitions, grouped by leaf. SHOW CLUSTER STATUS will achieve that. It orders the results by node ID, so you can easily see all the partitions on each leaf together. Additionally it will show all the partitions for all databases so you can see everything that is on each leaf. Check out our doc (linked above) to see an example output.


#5

Thank you for the response on this question.

Show cluster status was showing different number of partitions than this configuration, and was why I asked this question. It looks like the OPTIMIZE command changed the default_partitions_per_leaf config and was why it is different. Since the master aggregator was not restarted, the value updated by the execution of OPTIMIZE was not effective - which is good in our case. I’m all set with this question now.