0

In the Abridged Q Language Manual Arthur mentioned:

`s#table marks the table to use binary search and marks first column sorted

And if we look into 3.6 version:

N:1000000;
t1:t2:([]n:til N; m:N?`6);
t1:update `p#n from t1;
t2:`s#t2;
(meta t1)[`n]`a / `p
(meta t2)[`n]`a / `p
attr t1 / `
attr t2 / `s

\ts:10000 select count i from t1 where n in 1000?N
/ ~7000
\ts:10000 select count i from t2 where n in 1000?N
/ ~7000

we find that yes, t2 has this attribute: s.

But for some reason an attribute on the first column is not s but p. And also search times are the same. And the sizes of both tables with attributes are the same - I used objsize function described in AquaQ blogpost to ensure.

So are there any differences in 3.6+ version of q between 's#table and a table with '#p attribute on a first column?

egor7
  • 4,678
  • 7
  • 31
  • 55
  • 1
    "And the sizes of both tables with attributes are the same" not quite sure which attribute you are referencing, but `s# has no overhead as there is no additional structure to maintain for a sorted list. – user20349 Oct 17 '20 at 10:37

1 Answers1

1

I think the only way that the s# on the table itself would improve search times is if you were doing lookups using ? as described here: https://code.kx.com/q/ref/find/#searching-tables

q)\ts:100000 t1?t1[0]
105 800
q)\ts:100000 t2?t2[0]
86 800
q)
q)\ts:100000 t1?t1[500000]
108 800
q)\ts:100000 t2?t2[500000]
83 800
q)
q)\ts:100000 t1?t1[999999]
107 800
q)\ts:100000 t2?t2[999999]
83 800

It behaves differently for a keyed table (turns it into a step function) but I think that's beyond the scope of your original question.

terrylynch
  • 11,844
  • 13
  • 21
  • 1
    Got it - one hypostasis of table is a list of dictionaries, so applying an attribute to the list makes faster searching through it (binary search). – egor7 Oct 14 '20 at 12:57