Querying proper instance(leader) based on parition key

Hello!
We are researching possibility to use Yugabyte(YSQL) and found out that there is a lot of data transfered between nodes if query is executed not against leader. In our benchmarks difference is nearly 2x.
When random node is queried we have 2.3 GB/s, when leader is queried - 5.5GB/s

Query is quite simple - it reads all data by partition key

SELECT customerid, blob
	FROM filters.customersdefault
	WHERE tenantid = @tenantId AND partitionid = @partitionId

Table structure is: tenant_id, partition_id, id, blob_data. PK ((tenant_id, partition_id), id).

Is there are a way to query tablet leaders, so connection with proper host will be constructed by application?
So fаr we can obtain hash_split value and tablets per node, but can’t find how to identify leader of tablet (unless using UI at :7000).
yb_hash_code - to get hash value
yb_local_tablets - to get all tablet “ranges”

Thanks in advance!

Maybe explore Follower Reads?

Maybe this is helpful too?
Map a Table Row to the Tablet Leader Node

Or this one?
Display Tablet Leader/Follower Status on a Node

Using follower readers will be a little trade off, which I would like to avoid if possible.
It’s sad that there is no simple YSQL query for this, but at least there is a way to get this data.
Thank you!

hi @TimurMannapov

Good point.

For YCQL, we have a virtual/system table system.partitions, which provides the location of the tablets and who the leader is etc.

ycqlsh:k> select * from system.partitions where keyspace_name='k' and table_name='t';

 keyspace_name | table_name | start_key | end_key | id                                   | replica_addresses
---------------+------------+-----------+---------+--------------------------------------+-------------------------
             k |          t |        0x |  0x8000 | 861d6bfc-ee6a-62be-1b43-83629ace5b00 | {'127.0.0.1': 'LEADER'}
             k |          t |    0x8000 |      0x | 564780f6-0f89-48af-f74c-cc4515b2de4e | {'127.0.0.1': 'LEADER'}

We’ll look into exposing something equivalent like this, as a SQL view, for YSQL tables as well.