Database Reference
In-Depth Information
partition in this list is what determines the partition number, so the first element in the
list is partition
0
, the second partition is
1
, and so on.
The partition is selected by the output of the
RUN ON
function, and then masked by
the right number of bits to map it on partitions. So, if
hashtext(i_username)
re-
turns 14 and there are four partitions (2 bits, mask binary 11 or 3 in decimal), the
partition number will be 14 and 3 = 2, and the function will be called on partition
2
(starting from zero), which is the third element in partition list.
Note
The constraint that the number of partitions has to be a power of two may seem
an unnecessary restriction at first, but it was done in order to make sure that it is,
and it will remain to be, easy to expand the number of partitions without the need
to redistribute all the data.
For example, if you tried to move from three partitions to four, most likely 3/4th
of the data rows in partitions
0
to
2
have to be moved to new partitions to evenly
cover
0
to
3
. On the other hand, when moving from four to eight partitions, the
data for partitions
0
and
1
is exactly the same that was previously on partition
0
,
2-3 is old 1 and so on. That is, your data does not need to be moved immediately,
and half of the data does not need to be moved at all.
The actual configuration of the cluster, the definition of partitions can be done in two
ways, either by using a set of functions in schema
plproxy
, or you can take ad-
vantage of the SQL/MED connection management. (SQL/MED is available starting
PostgreSQL 8.4 and above.)
Configuring PL/Proxy cluster using functions
This is the original way to configure PL/Proxy, which works on all versions of Post-
greSQL. When a query needs to be forwarded to a remote database, the function
plproxy.get_cluster_partitions(cluster)
is invoked by PL/Proxy to get
the connection string to use for each partition.
