Hi all,
@Janos: The patch didn't go through but I get the idea. FYI: in most apache
lists attachments are not allowed
Since people do not have strong feelings about this I am inclined to move
forward with Janos suggestion and accept all three properties for
specifying compactions.
I just logged
Hi Stamatis,
The attached one is a more generic proposal: basically moves out target
queue resolution to CompactorUtil.getCompactorJobQueueName as it is already
in use for the StatsUpdater.
There then the old properties are used based on a new fallback config prop.
Fallback is only for statement (
Thanks Janos for the feedback.
If I understand well your suggestion is support all of the properties below
for table level compactions and treat them as equivalent:
* compactor.mapred.job.queue.name
* compactor.mapreduce.job.queuename
* compactor.hive.compactor.job.queue
It is something that cros
Hi Stamatis,
the proposal seems reasonable to me.
I think that setting the two properties you mention, independently from the
underlying execution engine in use, should lead to the same result.
In addition, I also agree that we should deprecate the per-execution engine
properties.
Best regards,
Hi all,
This email is an attempt to converge on which Hive/Tez/MR properties
someone should use in order to schedule a compaction on specific queues.
For those who are not familiar with how queues are used the YARN capacity
scheduler documentation [1] gives the general idea.
Using specific queues
