[darrenwsun]

With qsql, the full column is searched before the result is presented. With key lookup, the search stops when it finds the first match. This is where the performance gain from key lookup comes from.

> The keys are basically nodes on a BST ( binary search tree ) which should look up in O(log(n)) time given n is size of the table

This isn’t true. KDB’s keyed table, or more generally a plain dictionary, does not use hashing techniques like Java’s HashMap. Lookup is done by searching through the table/list linearly. If one wishes less time for the lookup, grouped (conceptually the same as index) or parted (conceptually a space-optimized index that assumes data are sorted) attributes help.

 

[darrenwsun]

Thanks Leah. My PC sits in a corporate network and I’m pretty sure the issue is due to firewall. I can request a rule update but I need to know the remote endpoint it tries to connect to, which is what I hope to know from the community.

I know 32-bit works without always-on internet, but I do wish to play things around using Kx Developer which doesn’t work with 32-bit version.

[darrenwsun]

If that’s what you really have to do, one way is to split those tables into multiple instances and use .z.pd (slave processes) for parallel computation. This adds to the complexity though so it’s not necessarily worth the cost.

[darrenwsun]

Is it the bottleneck that needs optimization? insert is quite cheap.