The .Q.qp doc says 0b
for splayed table, but on KDB 4.0 it’s actually 0
. Is it a bug, or there is a new way to check if a table is splayed?
q):./t/ set ([] v1:10 20 30; v2:1.1 2.2 3.3)
:./t/ q)\l ./t `t q)0b~.Q.qp t 0b q)0~.Q.qp t 1b
The .Q.qp doc says 0b
for splayed table, but on KDB 4.0 it’s actually 0
. Is it a bug, or there is a new way to check if a table is splayed?
q):./t/ set ([] v1:10 20 30; v2:1.1 2.2 3.3)
:./t/ q)\l ./t `t q)0b~.Q.qp t 0b q)0~.Q.qp t 1b
If you refer here: https://code.kx.com/q/basics/syscmds/#l-load-file-or-directory
name
name
, without loading any columns into memoryWhen you are running, \l .t -> you are loading the object as t in root. Thus .Q.qp is showing t as 0
% ls -lrth t
total 16
-rw-r--r-- 1 sujoyrak\*\*bleep\*\* staff 40B Sep 17 17:20 v1
-rw-r--r-- 1 sujoyrak\*\*bleep\*\* staff 40B Sep 17 17:20 v2
% q
KDB+ 4.0 2021.07.12 Copyright (C) 1993-2021 Kx Systems
q)\l .
q)\a
,`t
q).Q.qp t
0b
q)\l t
`t
q).Q.qp t
0
Thanks @sujoy13. What confused me is “directory of a splayed table”, which I interpreted as directory t
as in your example.
A follow-up question: what is the real runtime difference between \l .
and \l t
for this particular example? The latter form also maps the table without copying data from disk to memory. By the way t
is layed out on the disk, it is a splayed table…