SQL range partitioning using arithmetical elements (addition) on usigned ints - will it optimise WHERE queries? (MySQL, PostgreSQL) - mysql

Question

I read about range partitioning in MySQL (and PostgreSQL) here. I am also aware, that if I partition my table, some WHERE queries will be optimised.
For example partitioning by used_at date:
PARTITION BY RANGE (used_at) (
PARTITION p0 VALUES LESS THAN ('2012-01-01'),
PARTITION p1 VALUES LESS THAN ('2013-01-01'),
PARTITION p2 VALUES LESS THAN ('2014-01-01'),
);
Will make querting things like:
WHERE used_at >= '2013-05-01' AND used_at < '2013-09-01'
faster for example as it will only use a 1/3 size subtable practically for the search.
Well the question is if I have two tables:
user (3 000 000 records):
user_id UNSIGNED INT ...
...
messages (50 000 000 records)
sender UNSIGNED INT (refers to user)
recipient UNSIGNED INT (refers to user)
We get threads like:
WHERE ... (sender = 1234567 OR recipient = 1234567)
...
GROUP BY (sender + recipient)
Well, my question is:
a) Am I able to partition by
PARTITION BY RANGE (sender + recipient) (
PARTITION p0 VALUES LESS THAN (1000000),
PARTITION p1 VALUES LESS THAN (2000000),
...
PARTITION p5 VALUES LESS THAN (6000000),
);
?
b) If yes, will it optimise WHERE conditions like
WHERE ... (sender = 1234567 OR recipient = 1234567)
in case of unsigned ints?
The question is basically about MySQL but I am also curious about PostgreSQL and Oracle for the future.

Answer 1

MySQL...
WHERE ... (sender = 1234567 OR recipient = 1234567)
Does not optimize well. it would be better to do
( SELECT ... WHERE sender = 1234567 )
UNION DISTINCT
( SELECT ... WHERE recipient = 1234567 )
and have separate indexes on sender and recipient (or at least starting with each).
PARTITION can handle a very few expressions, not including (x+y).
GROUP BY (sender + recipient)
cannot be optimized by any form of INDEX or PARTITION. It will involve a full scan and probably a filesort.
If you meant GROUP BY sender, recipient, that's another matter.
WHERE used_at >= '2013-05-01' AND used_at < '2013-09-01'
Does not benefit from partitioning, at least no compared to having some INDEX starting with used_at.
WHERE used_at >= '2013-05-01' AND used_at < '2013-09-01'
AND x = 1
Would like INDEX(x, used_at)
WHERE used_at >= '2013-05-01' AND used_at < '2013-09-01'
AND x > 1
Is problematical -- two ranges. In this example BY RANGE partitioning on either x or used_at would be beneficial. This is because: first "partition pruning" would first pick the desired partition(s), then ordinary indexing (if any) would take over to finish the task. (It is impossible to say what the optimal INDEX would be without further details on the table and the data distribution.)
I did not get your point on users plus messages.