My apologies, Vladimir.
The query-plans are swapped around (oops!).
The query-plan for the efficient query is in the 'bad' file. And
vice-versa...
Thanks,
Jose
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
The difference in query plans is a 'bad' one use PUBLIC.TEST_DATA_K_V_ID
index instead of PUBLIC.TEST_DATA_ID_K_V.
Have you tries to remove other indices and left TEST_DATA_ID_K_V only?
It looks weird for me, the 'good' query plan shows unicast requests as ID
is affinity field, but 'bad'
Hi Jose,
I am a bit lost in two provided explains. Both "godd" and "bad" contain "k
= 'trans.cust.first_name'" condition. Could you please confirm that they
are correct? Specifically, I cannot understand why this condition is
present in "good" explain.
On Tue, Nov 27, 2018 at 12:06 PM joseheitor
1. - I have a nested join query on a table of 8,000,000 records which
performs similar or better than PostreSQL (~10ms) on my small test setup (2x
nodes, 8GB, 2CPU):
SELECT
mainTable.pk, mainTable.id, mainTable.k, mainTable.v
FROM
public.test_data AS mainTable
